Getting started with Claude Code in November 2026: the complete guide to Python, IDE and database
Twenty customers book the same chair at once, and all twenty get in. How to start with Claude Code and Python: installation, plans, choosing an IDE, SQLite or PostgreSQL, CLAUDE.md and permissions, with measured results and a real session.

Twenty people try to book chair 1 at a hair salon at the same moment, Saturday at 10:00. How many appointments end up in the database? I tested it with the code you get when you literally write "check whether it is free, then save it". The answer was twenty. In five out of five attempts.
Code that "checks first, then saves" looks just as sensible to a language model as it does to you, and every test with a single user passes. Claude Code writes you such a function in half a minute, with neat tests around it. Whether those tests check the right thing is up to you. That is what this guide is about. In November 2026, Claude Code demonstrably writes good Python. Whether the result holds up depends on three things you set up before the first line of code exists: which checks Claude has to pass, what it is allowed to do on your machine, and which database you choose.
Everything in this article was checked or measured on 3 November 2026: Claude Code 2.1.317 with Opus 5.5, Python 3.14.10, uv 0.13.7, SQLite and PostgreSQL 18.6. The example project is a small booking API for a hair salon. Claude Code added a feature to it in a real session, and what went right and wrong is in here too.
Short answer. Install Claude Code with the native installer and get at least a Pro plan ($20 a month). Start a Python project with
uv init, and put exactly which commands mean "done" inCLAUDE.md: tests, ruff and a type checker. Choose SQLite until you have several servers or many concurrent writers, then choose PostgreSQL. Either way, let the database block double bookings, not your Python code. Any IDE works, because Claude Code runs in the terminal. The VS Code extension is the most complete; the JetBrains plugin is still in beta.
What Claude Code is, and how it differs from a chat window
Claude Code is a program in your terminal that lets Claude work inside your project folder. It reads your files, edits them, runs commands such as pytest, reads the output and tries again. A chatbot gives you code to paste. Claude Code pastes it itself, runs the tests and sees what fails.
That sounds like a detail, but it decides how you work with it. Quality depends less on how cleverly you phrase your request, and more on what Claude can check. Anthropic's own best practices say the same: give Claude a check that passes or fails, and ask for evidence, meaning the command and its output. A project without tests is, for Claude Code, a kitchen without a tasting spoon.
Which plan do you need for Claude Code?
The free plan does not include Claude Code. The cheapest way in is Pro. The prices on claude.com/pricing are in dollars, excluding VAT:
| Plan | Price per month | Usage | For whom |
|---|---|---|---|
| Pro | $20 ($17 billed yearly) | limit per 5 hours and per week | learning, building one evening a week |
| Max | $100 | 5 times Pro | daily work |
| Ultra | $200 | 10 times Pro per week, no 5-hour limit | long sessions, several agents at once |
| Team / Enterprise | per seat | varies | organisations with central management |
| API (Console) | per token | no fixed limit | automation, CI |
Reading an older guide? The plan it calls "Max 20x" is now Ultra.
To give you a sense of cost: the feature Claude Code built later in this article cost $0.60 across two runs at API rates. That covered 15 turns and about a minute of compute. On a subscription you do not pay that separately; it counts towards your limit.
Which model does Claude Code use?
On every paid plan, Opus 5.5 is the default. With /model you switch to sonnet, haiku, fable or opusplan. That last one plans with Opus and executes with Sonnet. With /effort you set how long the model thinks: low, medium, high, xhigh or max. In Claude Code the default is medium.
| Model | API price per million tokens (in / out) | When |
|---|---|---|
| Fable 5.1 | $10 / $50 | the heaviest reasoning; never the default |
| Opus 5.5 | $4 / $20 | the default, for nearly everything |
| Sonnet 5.5 | $2 / $10 | many small tasks, a tight limit |
| Haiku 5.5 | from $0.10 / $0.50 | subagents that search and summarise |
All four have a context window of one million tokens. A mid-sized codebase fits in it whole. Still, "everything in context" is not a way of working, as you will see further on. My advice for beginners: leave the model on the default. A session rarely gets better with a different model. It does get better with a better check.
Installing Claude Code on Windows, macOS and Linux
The recommended route is the native installer. It updates itself automatically afterwards.
# macOS, Linux and WSL
curl -fsSL https://claude.ai/install.sh | bash
# Windows (PowerShell)
irm https://claude.ai/install.ps1 | iex
# then, in your project folder
claude Prefer a package manager? Homebrew (claude-code), WinGet (Anthropic.ClaudeCode) and npm (@anthropic-ai/claude-code, with Node 22 or later) all work. They all install the same binary. After installing, claude doctor checks that everything is in order.
On Windows, also install Git for Windows. It is not required, but with Git Bash, Claude Code runs its shell commands in bash. Without it, it falls back to PowerShell. That works, but most examples in documentation and on forums are bash. Want the sandbox, which shields Claude Code from the rest of your system? Then you need WSL 2: the sandbox does not exist on native Windows.
Python in November 2026: uv, 3.14 and the toolbox
For a new Python project in 2026 there is little reason to start with pip, venv and a loose requirements.txt. Astral's uv installs Python itself, creates the virtual environment, manages dependencies and runs commands. All in one program.
For Claude Code that matters more than it seems. With uv there is exactly one way to run anything: uv run pytest, uv run ruff. Claude does not have to guess whether the venv is active. That saves you the familiar ModuleNotFoundError, which otherwise costs three turns before the model realises it is using the wrong Python.
uv init --package --python 3.14 salon
cd salon
uv add fastapi "uvicorn[standard]"
uv add --dev pytest httpx ruff ty Which Python version? Python 3.15.0 was released on 9 October 2026, with lazy imports and UTF-8 by default, among other things. For this project I chose 3.14. It is a year old, free-threading is officially supported in it, and it gets updates until October 2030. Take 3.15 if all your dependencies ship wheels for it. In a web application like this one you will hardly notice the difference.
The rest of the toolbox, with the versions I used:
| Task | Tool | Version | Note |
|---|---|---|---|
| tests | pytest | 9.2.0 | the check everything revolves around |
| lint and format | ruff | 0.17.3 | replaces flake8, isort and black |
| types | ty | 0.0.96 | fast, but still beta; pyrefly 1.4 is stable |
| web API | FastAPI | 0.162.0 | with Pydantic 2.14.2 for validation |
Why a type checker when you already have tests? Because Claude Code sometimes calls a function with an argument that does not exist, in a place no test touches. The type checker finds that in a second. The user who happens to take that path only finds it in production.
Which IDE is best for Claude Code?
The honest conclusion: the IDE matters less than you think. Claude Code runs in the terminal, so it works next to any editor. The integrations mainly add two things: you see changes as a diff in your own editor, and whatever you select goes along as context automatically.
| IDE | Integration | Strong at | Watch out |
|---|---|---|---|
| VS Code | extension "Claude Code" (anthropic.claude-code) | review and edit the plan before you approve it, inline diffs with accept or reject per change, @-mentions with line ranges, checkpoints | requires VS Code 1.94 or later |
| PyCharm (and other JetBrains IDEs) | plugin "Claude Code [Beta]" | diffs in the IDE's diff viewer, your selection goes along, Claude reads the IDE's inspections | beta; install the CLI separately, connect with /ide |
| Cursor and other VS Code forks | the same extension, via Open VSX | if you already use Cursor | two AI assistants in one window sometimes work against each other |
| Zed | "Claude Agent" via ACP | fast editor, agent in a panel | separate login with /login |
| No IDE | terminal, desktop app, claude.ai/code | works anywhere, including on a server | no inline diff |
My pick for someone starting with Python and Claude Code is VS Code with the extension. That is not a verdict on the editor but on the integration. It is the most complete, and the plan view in particular helps: you read what Claude intends to do and adjust it before a single file changes. Already working in PyCharm? Do not switch. Since 2025.1, PyCharm is one product with a free core, and its debugger and database view are stronger than what VS Code offers out of the box. The JetBrains plugin gets the essentials right. How that works in practice is in my earlier article on Claude Code in PhpStorm; PyCharm works the same way.
Which database should you choose for a Python project with Claude Code?
This is where most beginner guides go wrong. They compare databases on speed and popularity. For an application Claude Code writes for you, one question matters most: who guards the rules of your data? A language model writes logic that is correct in a test with one user. That it breaks under concurrent use is something it does not see by itself, and neither do you until it happens.
Back to the salon. The rule is simple: no two appointments may overlap on one chair. I had twenty threads book chair 1 for Saturday 10:00 to 10:30 at the same time, in four ways, and repeated each variant several times.

What happens, per variant:
- SELECT first, then INSERT, without a transaction. All twenty threads see an empty schedule, and all twenty save their appointment. Nineteen double bookings, in 5 out of 5 rounds. A test with one user passes just fine.
- The same code inside a plain
BEGIN. The data is now correct: there is one appointment. But the other nineteen getdatabase is lockedwithin 0.03 seconds, despite a five-second busy_timeout. The cause: a transaction that started by reading and then wants to write cannot wait in WAL mode, because its snapshot is out of date. For the customer that means a 500 error instead of "this time is already taken". BEGIN IMMEDIATE. The write lock closes before the check. The threads wait for each other, one books, the rest get a clean "taken". This is the code below.- PostgreSQL 18 with only a constraint. The database itself refuses every overlap, and the data was correct in all 20 rounds. But in 3 of the 20 rounds the race ended in a chain of deadlocks. The nineteen losers got
DeadlockDetectedinstead of a clean refusal, and the round took 18 to 19 seconds. On every deadlock, PostgreSQL first waits one second (deadlock_timeout), and those waits stack up. - PostgreSQL 18 with the constraint plus an advisory lock per chair. In 20 out of 20 rounds: one booking, nineteen times "taken", about 0.09 seconds per round.
None of these problems surface in an ordinary test. So I added a test that has twenty threads book at once, and a rule in CLAUDE.md that explains why BEGIN IMMEDIATE is mandatory. That way Claude Code reads about the trap in every session.
SQLite: the right choice until you need a second server
SQLite is built into Python, needs no server and fits in one file. Claude Code can create that file in a temporary folder during a test and throw it away afterwards. For an application on one server with a reasonable number of users it is a full-fledged choice, provided you set three things: WAL mode, a busy_timeout, and STRICT tables. That last one refuses text in a column that should hold a number. Without STRICT, SQLite simply stores the text.
One thing surprises many people. By default the sqlite3 module still opens transactions by itself, in a way you do not expect. Python 3.12 added the autocommit argument, and the documentation recommends setting it. The default only changes "in a future release". I set it to True and write BEGIN and COMMIT myself. Then the code says what happens.
src/salon/db.py
"""Appointment storage in SQLite. One connection per request or per thread."""
import sqlite3
from pathlib import Path
SCHEMA = """
CREATE TABLE IF NOT EXISTS appointment (
id INTEGER PRIMARY KEY,
chair INTEGER NOT NULL,
client TEXT NOT NULL,
start TEXT NOT NULL, -- ISO 8601, for example 2026-11-14T10:00
"end" TEXT NOT NULL,
CHECK ("end" > start)
) STRICT;
CREATE INDEX IF NOT EXISTS appointment_chair_start ON appointment (chair, start);
"""
class Taken(Exception):
"""The chair is already booked for (part of) this time slot."""
def connect(path: str | Path) -> sqlite3.Connection:
# autocommit=True (Python 3.12+): the module no longer opens transactions
# by itself, so we issue BEGIN and COMMIT explicitly.
conn = sqlite3.connect(path, autocommit=True, timeout=5, check_same_thread=False)
conn.row_factory = sqlite3.Row
conn.execute("PRAGMA journal_mode = WAL")
conn.execute("PRAGMA busy_timeout = 5000")
conn.executescript(SCHEMA)
return conn
OVERLAP = 'SELECT 1 FROM appointment WHERE chair = ? AND start < ? AND "end" > ?'
INSERT = 'INSERT INTO appointment (chair, client, start, "end") VALUES (?, ?, ?, ?)'
def book(
conn: sqlite3.Connection, chair: int, client: str, start: str, end: str
) -> int:
"""Book an appointment, or raise Taken. BEGIN IMMEDIATE takes the write lock
before the check, so no second booking can slip in between check and INSERT."""
conn.execute("BEGIN IMMEDIATE")
try:
if conn.execute(OVERLAP, (chair, end, start)).fetchone():
raise Taken(f"chair {chair} is taken between {start} and {end}")
row_id = conn.execute(INSERT, (chair, client, start, end)).lastrowid
conn.execute("COMMIT")
except BaseException:
conn.execute("ROLLBACK")
raise
assert row_id is not None
return row_id
def cancel(conn: sqlite3.Connection, appointment_id: int) -> bool:
"""Delete an appointment. Returns False if it did not exist. A single DELETE is
atomic (no check-then-write), so BEGIN IMMEDIATE is not needed here."""
return (
conn.execute("DELETE FROM appointment WHERE id = ?", (appointment_id,)).rowcount
> 0
)
def appointments_on(conn: sqlite3.Connection, day: str) -> list[dict]:
rows = conn.execute(
'SELECT id, chair, client, start, "end" FROM appointment '
"WHERE start >= ? AND start < date(?, '+1 day') ORDER BY chair, start",
(day, day),
)
return [dict(r) for r in rows] A detail worth remembering: the Python 3.14.10 that uv installed ships SQLite 3.50.4, while the latest SQLite is 3.54.1. Which SQLite you have depends on your Python build, not on what sqlite.org lists. Check it with sqlite3.sqlite_version before Claude uses a feature your version does not have yet.
PostgreSQL: when several processes write at once
If your application runs on more than one server, or many users need to write at the same time, choose PostgreSQL. The current version is 18; version 19 is scheduled for 19 November 2026. PostgreSQL 18 can do something that fits this example well: temporal constraints. With WITHOUT OVERLAPS in the primary key, the database itself refuses any overlapping appointment on the same chair. However sloppy the application code is, double booking is no longer possible.
pg_book.py
"""Booking in PostgreSQL 18. The constraint guarantees that two appointments on one
chair never overlap; the advisory lock makes concurrent bookings for the same chair
queue up neatly instead of deadlocking each other."""
import psycopg
from psycopg import errors
SCHEMA = """
CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE TABLE IF NOT EXISTS appointment (
chair int NOT NULL,
client text NOT NULL,
during tstzrange NOT NULL,
PRIMARY KEY (chair, during WITHOUT OVERLAPS)
);
"""
class Taken(Exception):
pass
def book(
conn: psycopg.Connection, chair: int, client: str, start: str, end: str
) -> None:
try:
with conn.transaction():
conn.execute("SELECT pg_advisory_xact_lock(%s)", (chair,))
conn.execute(
"INSERT INTO appointment (chair, client, during) VALUES (%s, %s, tstzrange(%s, %s))",
(chair, client, start, end),
)
except errors.ExclusionViolation as error:
raise Taken(f"chair {chair} is taken") from error The constraint guarantees correctness. The advisory lock queues concurrent bookings for the same chair, which makes the deadlocks from the measurement disappear. Bookings for different chairs do not get in each other's way.
MySQL and DuckDB
If you already run MySQL, you can keep using it. Watch the version: MySQL 8.0 stopped receiving updates in April 2026, and 8.4 and 9.7 are the LTS versions. MySQL has no constraint like WITHOUT OVERLAPS, so there you handle it with SELECT ... FOR UPDATE on a row per chair. How to combine AI and databases further is in my article on AI and databases in web applications. DuckDB (2.0) is excellent for analysis on large files, but it is not meant as the database behind a web application where many users write at once.
| Situation | Choose | Why |
|---|---|---|
| Prototype, internal tool, one server | SQLite | no server, tests in a temporary file, Claude can run everything itself |
| Several servers or workers that write | PostgreSQL 18 | concurrent writes, constraints such as WITHOUT OVERLAPS |
| Existing MySQL environment | MySQL 8.4 or 9.7 | do not migrate without a reason; lock with FOR UPDATE |
| Reports over millions of rows | DuckDB next to your main database | fast for analysis, not for many concurrent writers |
Setting up the project: CLAUDE.md, permissions and a hook
At the start of every session, Claude Code reads the file CLAUDE.md in the root of your project. Whatever is in it, you never have to repeat. /init writes a first version for you. Anthropic's guideline is clear: keep it short, under 200 lines, and include only what Claude cannot work out from the code: the commands, the conventions and the traps. An architecture description does not belong there. Claude reads that from the code itself.
CLAUDE.md
# Hair salon booking API
FastAPI + SQLite, Python 3.14, managed with uv. Four chairs; an appointment stays within one day.
## Commands
- Tests: `uv run pytest -q`
- Lint and format: `uv run ruff check --fix` and `uv run ruff format`
- Types: `uv run ty check`
- Server: `uv run fastapi dev src/salon/app.py`
## Rules
- Write a failing test in `tests/` first, then the code. Done = all three checks green.
- All SQL lives in `src/salon/db.py`, with `?` parameters. Never f-strings in SQL.
- Writes that check first and then insert: always inside `BEGIN IMMEDIATE`
(see `db.book`). A plain `BEGIN` returns "database is locked" under concurrent
bookings instead of a clean 409.
- Times are ISO 8601 without a time zone, the salon's local time. Intervals are half-open: [start, end).
- Do not add dependencies without asking. Look at the rule about BEGIN IMMEDIATE. It is not there to explain the code, but because the right choice cannot be read from the code itself. Without that rule, a plain BEGIN looks just as sensible.
Rules that must always hold do not belong in CLAUDE.md. A language model reads those as advice. What must always happen goes in .claude/settings.json, as permissions and hooks:
.claude/settings.json
{
"permissions": {
"allow": [
"Bash(uv run pytest *)",
"Bash(uv run ruff *)",
"Bash(uv run ty check *)",
"Bash(git status)",
"Bash(git diff *)"
],
"deny": [
"Read(./.env)",
"Read(./*.db)",
"Bash(uv add *)",
"Bash(git push *)"
]
},
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "uv run ruff check --fix --quiet && uv run ruff format --quiet"
}
]
}
]
}
} The allow rules let Claude run the checks without asking for permission each time. The deny rules always apply, in every mode: reading .env, adding a dependency or pushing is simply not possible. The PostToolUse hook runs ruff after every edit, so formatting is never something you or Claude have to think about again.
A trap I ran into myself. In the first run with this file, Claude Code was not allowed to run uv run pytest, despite the allow rule. The debug log gave the reason: "Dropped 5 project-scoped permissions.allow entries — workspace not yet trusted". A folder you have never opened and approved interactively may not grant itself permissions. The deny rules did take effect immediately. That is exactly right: a repository you just cloned cannot quietly allow its own commands. So open a new project once with claude and confirm that you trust the folder.
Since version 2.1.283, interactive sessions start in auto mode by default. In it, a classifier assesses risky actions, so you do not have to click for every command. Shift+Tab cycles through the modes: auto, manual, accept edits automatically, and plan mode. For a new feature I start in plan mode. Claude then only reads code and writes a plan, and you read that plan before anything changes.
Having a feature built: what happened in a real session
With bookings and the day overview done, I gave Claude Code one instruction, with no further explanation. The project was in Dutch, so the prompt was too; translated:
Customers must be able to cancel an appointment. Add DELETE /appointments/{id}: 204 if it works, 404 if the appointment does not exist. A cancelled time must be bookable again afterwards. Work according to CLAUDE.md: failing tests first, then the code, and finish with the three checks.
The first run took 34 seconds and 10 turns. Claude wrote five tests and a cancel function. Then it got stuck on the permissions, see the trap above, and its final report was honest. Translated: I wrote DELETE /appointments/{id} with the tests, but nothing has been run yet. [...] So it is not "done" according to CLAUDE.md. It did not report the tests as green, but as not run. That difference matters.
The second run, now with permission for the checks, took 27 seconds. Claude set the new code aside temporarily with git stash and showed that four of the five new tests then failed. Then it put the code back: 15 tests green, ruff clean, ty clean. And it reported something I had overlooked. The test "unknown id returns 404" also passed without the new code, because FastAPI already returns 404 when there is no route. So that test proves nothing. The model found this because CLAUDE.md asked for failing tests first. Without that rule, nobody would have noticed.
The code it wrote is small and correct (identifiers translated):
@app.delete("/appointments/{appointment_id}", status_code=204)
def cancel_appointment(appointment_id: int, conn: Conn) -> None:
if not db.cancel(conn, appointment_id):
raise HTTPException(status_code=404, detail="appointment not found") It also explained why no BEGIN IMMEDIATE is needed here: a single DELETE does not check anything first, so nothing can slip in between. It applied the rule from CLAUDE.md with understanding, not blindly.
One thing went wrong, and that was my doing. For the second run I used claude -p --continue. That picks the most recent session in the folder. That was not the build session, but a short test session I had run in between to investigate the permissions. So Claude started without any memory of its own work. It noticed this itself (translated: "those changes are not mine") and simply carried on from what was in the files. To continue a specific session, use --resume with the session ID.
The way of working that holds up
There are a hundred tips about Claude Code. These five decide whether you still enjoy your codebase after a month.
One task per session, and /clear in between
A million tokens of context does not mean it is wise to do everything in one conversation. Every failed attempt, every error message and every file read stays in there and influences what Claude does next. Anthropic recommends using /clear after two failed corrections and starting again with a better instruction. /context shows what is in the context, and /compact summarises the conversation without wiping it.
Plan first, then build in a clean session
For anything bigger than a small function, have Claude ask you questions in plan mode first. Have it save the result to a file such as SPEC.md, and start the build in a new session that only reads that file. You lose two minutes. You gain a session that is not cluttered with rejected ideas.
Undo works, but not for everything
Pressing Esc twice, or /rewind, takes you back to an earlier point in the session, including the files. What Claude changed through a shell command is not covered. A wiped database or a git reset does not come back with /rewind. So commit before you set Claude loose on something big. Git is your real safety net.
Work in parallel with worktrees
With claude --worktree name a session gets its own git worktree, a separate copy of your repository on its own branch. One session can work on cancellations while another works on email confirmations, without overwriting each other's files. If you want Claude to work more on its own, that is covered in more depth in letting Claude Code work autonomously.
Subagents, skills and MCP: only once you miss them
Claude Code can do much more. Subagents in .claude/agents/ handle subtasks with their own context. Skills in .claude/skills/ are fixed ways of working. MCP connects external systems, such as your database, with claude mcp add. And claude -p runs Claude Code without interaction, for example in a GitHub Action. Do not start there. A good CLAUDE.md, a test suite and two deny rules deliver more in the first weeks than ten skills. Add a skill only when you notice you are typing the same instruction for the third time.
The mistakes beginners make most often with Claude Code
- Not giving a check. "Build a booking system" produces code that looks good. "Build a booking system; done means
uv run pytestpasses, including a test with twenty simultaneous bookings" produces code that works. - Tests that prove nothing. A test that passes without the new code is decoration. Have Claude show you the failing test first. In the session above, that caught exactly such a test.
- Rules in CLAUDE.md that should be a hook or a deny rule. "Never commit .env" is a wish.
"deny": ["Read(./.env)"]is a rule. - Business rules only in Python. What must never happen, such as a double booking, a negative balance or an email address that appears twice, you let the database guard with a constraint. Python code that "checks first" breaks as soon as two requests arrive at once.
- One endless session. After an hour of back and forth, the model knows all about your first three ideas, and that gets in the way of the fourth.
Frequently asked questions
Can I use Claude Code for free?
No. You need at least a Pro plan ($20 a month), or a Console account that pays per token. Claude's free plan does not give access to Claude Code.
Do I need to be a good programmer to use Claude Code?
You need to be able to read and judge code. Claude Code writes the function, but you decide whether the tests test the right thing. You will not spot the race at the salon if you do not know it can exist. How the profession is shifting is in PHP and AI in 2027; the same applies to Python.
Does Claude Code work well with Python?
Yes. Python with uv, pytest and ruff is one of the easiest environments for Claude Code: one command to test, one to format, and error messages that say exactly what is wrong. In the test above it built a complete feature with tests in half a minute.
SQLite or PostgreSQL for a new project?
Start with SQLite if your application runs on one server, and set WAL, a busy_timeout, STRICT and BEGIN IMMEDIATE. Move to PostgreSQL once several processes or servers write at the same time. In both cases, put your hard rules in the database itself.
Do I need VS Code?
No. Claude Code works in any terminal, next to any editor. The VS Code extension and the JetBrains plugin make diffs and context nicer, but the work happens in the CLI.
Want to start tomorrow? Pick one small feature in a project that already has tests. Write in three lines in CLAUDE.md which commands mean "done", and ask Claude Code to show you the failing test first. If that works, you have learned the most important lesson. The rest is settings.
Further reading on this site
- Claude Code in PhpStorm: setup, the plugin and the habits that work
- Letting Claude Code work autonomously: auto mode, the Ralph loop and tmux
- Using Claude Code effectively: what actually works in 2026
- What AI did to databases for web applications, from Oracle to SQLite
- Claude Code for Windows maintenance: what it found, where it went wrong and which limits work
- Free high-quality images in Claude Code: the best model and the setup (November 2026)
- Herdr, Caprock and ccdeck compared: keeping track of several coding agents (November 2026)
Sources
- Anthropic, Claude Code documentation: setup, best practices, permission modes, model configuration, VS Code, JetBrains; changelog (version 2.1.317)
- Anthropic, pricing, the Ultra plan explained and models overview, accessed 3 November 2026
- Python Software Foundation, downloads and support periods and sqlite3 documentation; Astral, uv
- JetBrains, PyCharm as one product; Zed, external agents
- PostgreSQL, release notes 18 and PostgreSQL 19 RC 1; SQLite; Oracle, MySQL EOL notice
- Own test, 3 November 2026: Claude Code 2.1.317 with Opus 5.5 (two headless runs), Python 3.14.10 with SQLite 3.50.4, uv 0.13.7, FastAPI 0.162.0, pytest 9.2.0, ruff 0.17.3, ty 0.0.96, PostgreSQL 18.6 in Docker, psycopg 3; twenty threads per round


