DEV Community: Papan Sarkar

The AI Productivity Paradox: More Starts, Fewer Finishes

Papan Sarkar — Mon, 02 Nov 2026 08:30:09 +0000

AI didn't give developers more free time. It gave us more starts.

I'm a senior full-stack engineer and I use coding agents every day. Our capacity to implement ideas has grown much faster than our capacity to think them through. The numbers show it too. In Faros AI's telemetry from more than 10,000 developers, high-AI teams merged 98% more pull requests, but PR review time rose 91% and delivery at the company level didn't improve (Faros AI).

I think that's the real shift, and it's a management problem, not a tooling one.

TL;DR

Cheap implementation removed the old filter. When a feature took a month, the cost made you choose. Now a prototype takes an afternoon, so nothing makes you choose.
The data backs this up. In Faros AI's telemetry, developers on high-AI teams touched 47% more pull requests a day, and PR review time rose 91% (Faros AI). A Berkeley study found that AI intensified work instead of reducing it (HBR).
Better tools won't fix it. Google's DORA research found friction and burnout "unaffected by AI" (Jellyfish on DORA 2025). A tool can't decide what's worth doing.
Three rules I'd protect: one thing in progress per product, a written "done" before any code, and a weekly review of what to kill.

Why does AI make developers busier instead of freer?

Before coding agents, the cost of building did your prioritisation for you. If a feature took three weeks, you argued about it first. You wrote it down, cut scope and said no to the other four ideas, because you could see what they would cost. Most bad ideas died in that conversation, before anyone wrote code.

That filter is gone. Starting something now costs a prompt and a coffee. Finishing it costs what it always did: review, tests, edge cases, deployment, docs, support and, above all, the decisions. Every thing you start keeps a claim on your attention. It might be an open branch, a prototype that half works, or an agent waiting for an answer.

In practice it looks like this. You have three agent sessions open. None of them needs you all the time, but each one periodically needs a decision, a review or an answer. Every one of those is a context switch. A new model ships, the ideas come faster, you start more, and a few weeks later the review queue and the switching catch up with you.

Simon Willison described this pattern in February. He often runs two or three projects in parallel and gets a lot done, but his mental energy is mostly gone after an hour or two (Simon Willison). That isn't a complaint about the tools. It's what happens when the number of open loops goes up and the person holding them stays the same.

What the research says about AI and workload

The work got more intense, not smaller. Aruna Ranganathan and Xingqi Maggie Ye of Berkeley Haas spent April to December 2025 studying about 200 employees at a US tech company where AI use was optional (HBR). People took on a wider range of tasks, and work spilled into more hours of the day. Engineers spent more time reviewing and cleaning up colleagues' AI-generated output (The Star, via Inc.). The authors describe "a growing number of open tasks" and "a sense of always juggling, even as the work felt productive" (Simon Willison, quoting HBR).

People produced more, but companies didn't deliver more. Faros AI analysed telemetry from more than 10,000 developers across 1,255 teams (Faros AI). Here is what changed on teams with high AI adoption:

Metric (high-AI teams)	Change	Source
Tasks completed	+21%	Faros AI
Pull requests merged	+98%	Faros AI
Tasks touched per developer per day	+9%	Faros AI
PRs touched per developer per day	+47%	Faros AI
PR review time	+91%	Faros AI
Average PR size	+154%	Faros AI
Bugs per developer	+9%	Faros AI

Faros's conclusion: "no significant correlation between AI adoption and improvements at the company level" (Faros AI). Read the table as one story. People started more, touched more and opened bigger changes. Then all of it queued up for the same few reviewers.

This was visible before agents. In 2024, 77% of employees who use AI told the Upwork Research Institute the tools had added to their workload, and 39% pointed to time spent reviewing or moderating AI content (Upwork). In Atlassian's 2025 survey of 3,500 developers and managers, 68% said AI saved them more than 10 hours a week, while 50% lost 10 or more hours a week, mostly to organisational inefficiency (Atlassian). Saving time on typing doesn't help if the system around you can't take in what you produce.

Switching costs aren't new either. Gerald Weinberg's rule of thumb, as Johanna Rothman summarised it: a person on two tasks spends about 40% of their time on each and wastes 20%, and a person on four tasks spends 10% on each and wastes 60% (Rothman). Weinberg meant those as estimates, not measurements. A 2017 study in an educational setting measured a smaller but real cost: developers on two or more projects spent about 17% of their effort on cross-project interruptions (Tregubov et al., via Never Work in Theory). Gloria Mark's lab found that interrupted people work faster to compensate, but report more stress, frustration and time pressure (Mark et al., CHI 2008). That describes running five agents at once pretty well.

The case that this is fine

I want to be fair to the other side. The 2025 DORA findings are more positive than the anecdotes. Individual effectiveness rose the most with AI adoption, throughput and time on valuable work improved, and burnout didn't get worse on average (Jellyfish on DORA 2025). I'll add my own experience: the work is more fun without the boilerplate.

I agree with all of that, and it supports my point. DORA's headline is that AI is "an amplifier," magnifying an organisation's existing strengths and weaknesses (DORA 2025). If you already had a filter, AI makes you faster at the things that pass it. If cost was your only filter, AI took it away and gave you nothing in its place.

DORA's own follow-up says this plainly. Two of its seven AI capabilities are working in small batches and keeping a user-centric focus. As DORA puts it, "Speed is irrelevant if you are moving in the wrong direction" (Google Cloud).

It's a management problem, not a tooling one

The common response to "I'm drowning in agent output" is more tooling: an orchestrator, a dashboard of sessions, an agent that manages your agents. Every one of those makes starting even cheaper, so you end up with more starts.

What's scarce is attention and judgement, so manage them the way teams have always managed scarce capacity: limit work in progress. The Kanban Guide's rule is that you "must explicitly control the number of work items in a workflow from started to finished" (Kanban Guide). Basecamp's Shape Up makes the same point about scope: "Estimates start with a design and end with a number. Appetites start with a number and end with a design" (Shape Up, ch. 3).

Here's how I think about it. For years, the cost of building did three jobs we never had to do on purpose. Now each one needs a rule.

What the cost of building used to do	What it looks like now	The rule that replaces it
Forced you to pick one idea	Five prototypes in a week	One thing in progress per product
Forced you to think before building	The agent builds before you've decided	A written "done" before any code
Killed weak ideas before they started	Weak ideas live on as stale branches	A weekly review of what to kill

Rule 1: One thing in progress per product

"In progress" means it has a branch, an agent session waiting on you, or a PR that isn't merged. Each product gets one of those at a time. It's one per product, not one per person, because most of us (me included) work across several codebases. The point is that every product has a single lane.

Agents can still run in parallel inside that lane. One writes tests, one drafts the migration and one updates the docs, all for the same feature. What the rule stops is five agents building five different features that all land on your review queue on Thursday.

New ideas go on a list, not into a branch. A list costs nothing to keep. A branch costs attention every time you see it.

There are two exceptions. A production incident overrides everything. A spike (a short experiment to answer a question) is allowed, but it gets a time box, a label, and by default it's thrown away when the time runs out.

Rule 2: A written "done" before any code

Two lines is enough. If you can't write them, you don't understand the work yet, and an agent will happily build the wrong thing very fast. This is the thinking that the cost of building used to force on you. Now you have to do it on purpose.

I keep a short file at the root of the branch:

# DONE.md: checkout-retry
Done when: a failed card payment retries once after 24 hours and the
           customer gets exactly one email, not three.
Not doing: dunning sequences, SMS, admin UI changes.
Appetite: 2 days. Not merged by Friday = cut scope or kill it. No extensions.

"Not doing" is the line that matters most. It keeps the agent from gold-plating, and it keeps me from "while I'm in here" detours. The "Done when" line goes straight into the agent prompt, which is the same habit I covered in Use AI Coding Agents Like a Pro. The appetite line comes from Shape Up: you decide how much the work is worth before you see the design.

Do the thinking away from the LLM. Write the done on paper or in a plain file before you open the agent. Once a chat session is open, it pulls you toward starting.

Rule 3: A weekly look at what you started and should kill

Every Friday I spend 20 minutes listing everything open: branches, draft PRs, prototypes, agent threads, and anything I called a "quick experiment". Each item gets one of three verdicts:

Finish it next week. It moves to the single in-progress slot, or waits for it.
Park it. Write one paragraph on what you learned, then delete the branch. The paragraph is what you were actually keeping anyway.
Kill it. This is the default.

The default comes from Shape Up's "circuit breaker": "If they don't finish, by default the project doesn't get an extension" (Shape Up, ch. 8). Basecamp's reasoning is that one runaway project should never freeze newer projects that could matter more. With AI that matters even more, because restarting is cheap. A killed idea that turns out to be good costs you an afternoon to rebuild, and it'll be better the second time because you'll write the done first.

To get the list, I run this in each repo:

# Local branches with no commits in the last 7 days, oldest first
git for-each-ref --sort=committerdate refs/heads/ \
  --format='%(committerdate:short) %(refname:short)' |
  awk -v cutoff="$(date -v-7d +%F 2>/dev/null || date -d '7 days ago' +%F)" '$1 < cutoff'

# Your open pull requests (GitHub CLI)
gh pr list --author "@me" --state open

The date fallback covers both macOS and Linux. Anything that shows up two Fridays in a row doesn't get a third.

Before you start the next thing

Ask yourself these before you open a new branch or agent session:

Is something already in progress on this product? Finish it or kill it first.
Can I write "done when" in two lines, with a "not doing" line?
What's the appetite, and what happens when it runs out?
Who reviews this, and do they have room this week?
If this took a month instead of an afternoon, would I still build it?

The last question is my favourite. It puts back the filter that cost used to provide, without the cost.

The short version

AI made implementation cheap and left judgement as expensive as ever. If you don't decide what not to build, you end up with a pile of half-finished work and a tired team. Shipping fast still matters, but speed without a filter just turns into a longer to-do list.

If you're a founder planning an MVP and you want speed that turns into shipped features, this is how I run my projects: one lane per product, a written done for every feature, and a weekly cut. I build React/Next.js and Node.js products for clients. Get in touch. If you're a developer, the agent-side habits are in Use AI Coding Agents Like a Pro, and my two-agent review loop is in Claude Code vs Codex: How I Use Both on One Repo.

Sources

Originally published at papansarkar.com.

Claude Code vs Codex: How I Use Both on One Repo

Papan Sarkar — Sun, 01 Nov 2026 12:10:04 +0000

Claude Code leads the coding-agent tools in Stack Overflow's 2026 survey at 66%, ahead of GitHub Copilot at 59% (Stack Overflow 2026). Codex passed 5 million weekly active users in June, by OpenAI's own count (Constellation Research). Most "Claude Code vs Codex" posts try to name a winner. I run both on the same repo, and I've found it more useful to ask which job goes to which agent, and how to keep the two from drifting apart.

This post covers what each tool does better as of late October 2026, one instruction file both of them read, and the loop where one agent writes and the other reviews. The general habits (context, prompts, model choice) are in Use AI Coding Agents Like a Pro, so I won't repeat them here.

TL;DR

Same entry price, different defaults. Both are included in their vendor's $20/month individual plan (Claude pricing, Codex pricing).
Claude Code drives my interactive work. You can switch permission modes mid-session, hooks enforce hard rules, and its review runs in the background.
Codex is my second opinion and my scripted worker. It sandboxes at the OS level by default, its scripted mode starts read-only, and its GitHub reviews flag only P0 and P1 issues.
One AGENTS.md serves both. Codex reads it natively. Claude Code reads it too, or imports it from CLAUDE.md with one line.
Have the agent that didn't write the code review it. Models favour their own output, and that bias does the most damage when the model got it wrong.

Claude Code vs Codex at a glance

I checked every row against both vendors' docs on 30 October 2026. Both products ship changes weekly, so confirm a detail on the linked page before you rely on it.

	Claude Code	Codex
Where it runs	Terminal, VS Code, JetBrains, desktop app, web (docs)	CLI, IDE extension, ChatGPT desktop, web and mobile, Codex Cloud (docs)
Cheapest plan with it	Pro: $20/month, or $17/month billed annually (pricing)	Included from ChatGPT Free upward; Go is $8/month, Plus $20/month (pricing)
Heavy-use tier	Max, from $100/month (pricing)	Pro, from $100/month, currently with no five-hour limit (pricing)
Instruction file	CLAUDE.md; reads AGENTS.md if there's no CLAUDE.md (docs)	AGENTS.md, merged from the repo root down to your folder (docs)
Safety default	Auto mode, where a classifier checks actions; the OS-level Bash sandbox is opt-in (docs)	OS-level sandbox in `workspace-write` mode (docs)
Scripted mode	`claude -p` (docs)	`codex exec`, read-only by default (docs)
Local review	`/code-review`, on any plan (docs)	`/review`, or `codex review --base main` (docs)
GitHub PR review	Managed Code Review, Team and Enterprise plans only (docs)	`@codex review` or automatic reviews (docs)
Open source	No	CLI is Apache-2.0 (GitHub)

I left benchmark scores and model names out on purpose. Both lineups have changed several times this year, and published comparisons disagree with each other by wide margins. Test both on a real ticket from your own codebase instead.

Both are safe bets now

If you're a founder or CTO deciding which one your team should pay for, the market data says neither is a fringe pick:

73% of respondents in Stack Overflow's 2026 survey use coding assistants and agents daily (Stack Overflow 2026).
Anthropic said in February that Claude Code's run-rate revenue had passed $2.5 billion and that weekly users had doubled since January 1 (Anthropic).
OpenAI said in June that Codex had more than 5 million weekly active users, up more than 6x since its desktop app launched in February (Constellation Research).
The open-source Codex CLI repo has more than 130,000 GitHub stars (GitHub).

Both companies report their own numbers, and they measure different things (revenue versus weekly users), so don't read them as a head-to-head. The point is simpler: both tools will be around, so choose by how your team works, not by which vendor might fold.

Where Claude Code wins for me

Steering while it works. Shift+Tab cycles permission modes mid-session: manual approval, auto-accept edits, and plan (permission modes). On code I don't know yet, I start in plan mode, read the plan, then let it edit. That back-and-forth is where Claude Code feels best.

Rules that are actually enforced. An instruction file is a suggestion. Anthropic's docs say it plainly: Claude treats CLAUDE.md "as context, not enforced configuration," and to block an action no matter what, you use a PreToolUse hook (memory docs). "Never edit the migrations folder" belongs in a hook, not in a paragraph.

Review that doesn't flood the session. /code-review runs as a background subagent with its own context window, so the findings arrive without filling your conversation (code review docs).

One config across surfaces. The terminal, IDE, desktop and web surfaces share one engine, so the same CLAUDE.md, settings and MCP servers work in all of them (overview).

Where Codex wins for me

Sandbox first. Codex enforces its sandbox at the OS level: Seatbelt on macOS, bubblewrap on Linux and WSL2, and a native sandbox on Windows. The default mode lets it edit files and run routine commands inside the workspace, and nothing outside it (sandboxing). Since I was handed a Next.js repo wired to run malware on every npm run dev, I want an agent that runs unfamiliar code inside an OS boundary from the start. Claude Code can do this too with /sandbox; it just doesn't start that way.

Safe scripting by default. codex exec starts in a read-only sandbox unless you pass --sandbox workspace-write, and --output-schema makes it return JSON that matches a schema you give it (non-interactive mode). That makes it a good fit for CI jobs like triage reports.

Quiet PR reviews. On GitHub, Codex flags only P0 and P1 issues (Codex GitHub docs). Reviews with less noise are reviews people actually read.

A cheap way in for teams already on ChatGPT. Every ChatGPT plan from Free upward includes Codex, and Business costs $25 per user per month billed monthly (Codex pricing). If a client's team already pays for ChatGPT Business, trying Codex costs them nothing extra.

One AGENTS.md for both agents

The fastest way to get inconsistent code from two agents is to give them two sets of rules. You don't need two copies:

Codex reads AGENTS.md files from the repo root down to your working folder, one file per folder. Files closer to you override earlier ones, and the combined size caps at 32 KiB by default (Codex AGENTS.md docs).
Claude Code reads AGENTS.md when there is no CLAUDE.md. If both exist, it reads only CLAUDE.md, unless CLAUDE.md imports the other file (Claude Code memory docs).

That second rule is how most repos drift: someone adds a CLAUDE.md and Claude quietly stops reading the shared rules. My setup keeps AGENTS.md as the source of truth and makes CLAUDE.md a thin wrapper.

The shape of a good AGENTS.md (commands, non-obvious conventions, "done means") is in my habits post. The part that matters for two agents is a review section. Codex's GitHub reviews look for a ## Code Review Rules heading in the nearest AGENTS.md (Codex GitHub docs):

## Code Review Rules
- Flag any API route that skips the auth middleware
- Flag money math done in floats; amounts are integer cents
- Flag new env vars that aren't added to src/env.ts
- Ignore formatting and import order; the linter owns those

And the whole CLAUDE.md:

@AGENTS.md

## Claude Code only
- For schema changes, use the /db-migration skill instead of editing models by hand

Claude reads the imported file first, then the lines below it (memory docs). The import also works on older Claude Code versions that can't read AGENTS.md directly. Claude's /code-review follows your CLAUDE.md (docs), so with the import, both reviewers check the same rules.

The loop: one agent writes, the other reviews

In the habits post I argued for reviewing in a fresh context. Here I go one step further and use a different vendor's model.

The research reason: Panickssery, Bowman and Feng found that LLM evaluators recognise and favour their own outputs, and that the stronger the self-recognition, the stronger the bias (arXiv 2404.13076). A 2025 follow-up complicates this. For stronger models, most of that self-preference turned out to be justified, because their answers really were better. The harmful kind persisted when the model was wrong, and "stronger models struggle more to recognize when they are wrong" (arXiv 2504.03846). You need a review for exactly the times the writer is wrong. Neither paper tested coding agents reviewing diffs, so take this as a good reason to try the loop, not as proof that it works.

My loop:

Claude Code writes the feature on a branch, interactively, starting in plan mode.
Cheap checks run first. Typecheck and tests. An agent review is not a test suite, and I don't pay an agent to find type errors.
Codex reviews the branch against main without changing the working tree (Codex code review).
The findings go back to Claude with a triage prompt (below).
Swap roles when Codex wrote the branch: Claude's /code-review runs non-interactively with claude -p (headless docs).

The script I keep in the repo:

#!/usr/bin/env bash
# Usage: scripts/cross-review.sh [codex|claude] [base-branch]
# Ask the agent that did NOT write this branch to review it. Neither command edits files.
set -euo pipefail

reviewer="${1:-codex}"
base="${2:-main}"

# Cheap checks first; an agent review is not a test suite.
pnpm tsc --noEmit
pnpm vitest run

case "$reviewer" in
  codex)
    codex review --base "$base"
    ;;
  claude)
    # dontAsk denies anything that would need approval, so the review can read but not write.
    claude -p "/code-review ${base}...HEAD" --permission-mode dontAsk
    ;;
  *)
    echo "reviewer must be codex or claude" >&2
    exit 1
    ;;
esac

codex review takes exactly one target: --base, --commit, --uncommitted, or a custom prompt (Codex CLI reference). On the Claude side, dontAsk mode denies every call that would otherwise prompt, but reads and read-only commands still run (headless docs). Without --fix, /code-review only reports.

The triage prompt I paste into the writing agent with the findings:

Another reviewer flagged the issues below on this branch.
For each one, either fix it or reply in one line explaining why it is not a bug.
Don't change code the findings don't mention.
When you're done, run the typecheck and tests and show me the output.

<findings>

The "explain why it isn't a bug" clause is what makes this work. Without it, the writer accepts every finding and the code bloats. With it, I read a short list of rejections and make the call myself.

On GitHub, the same idea applies at team scale. Claude's managed Code Review starts with an @claude review comment (Claude Code Review), and Codex starts with @codex review (Codex GitHub docs). Don't turn both on for every PR. That doubles the noise. Ask for a review from the agent that didn't write the PR.

Which agent for which job

Job	My first pick	Why
Exploring code I don't know yet	Claude Code in plan mode	Reads and plans before any edit; `Shift+Tab` to switch modes
Feature work I want to steer	Claude Code	Mode switching, hooks for hard rules, background review
Running an unfamiliar repo or script	Codex	OS-level sandbox from the first command
CI jobs: triage, reports, lint fixes	`codex exec`	Read-only by default; schema-checked JSON output
A well-scoped ticket I want back as a PR	Either	Both run tasks in the cloud: Codex Cloud and Claude Code on the web
Second-opinion review	Whichever didn't write it	Different model, different blind spots
Team PR review on GitHub	The one you already pay for	Claude Code Review needs a Team or Enterprise plan; Codex reviews run through the ChatGPT Codex connector

What running both costs

At entry level, Claude Pro plus ChatGPT Plus comes to $40 per developer per month, or $37 with Claude billed annually (Claude pricing, Codex pricing). Heavy users hit limits sooner, and both vendors' next tier starts at $100 a month (Claude pricing, Codex pricing).

The cost that matters more for client work is data. Running two agents means two vendors see the code. Codex Cloud and Claude Code on the web run on vendor infrastructure, and Claude's managed Code Review isn't available to organisations with Zero Data Retention enabled (Claude Code Review). Check the client's contract before you add a second vendor, not after.

When I don't bother with two agents

Small, obvious changes. If I can describe the diff in one sentence, one agent and the test suite are enough.
No tests. Two agents agreeing is not verification. In Stack Overflow's 2026 survey, 48% of respondents said they trust AI when they can easily validate its answers (Stack Overflow 2026). Make validation easy first.
Code the client won't share with a second vendor. Use one agent and a fresh-context review from that same vendor. My reading of the 2025 self-preference paper is that this gets you most of the benefit.

The short version

Pick one agent to drive and use the other as the reviewer. Keep AGENTS.md as the single source of truth, run your tests before any agent review, and make the writing agent justify every finding it rejects.

If you're planning a product and want it built with this kind of review loop, I build React/Next.js and Node.js products for clients. Get in touch. To keep either agent accurate and cheap, start with Use AI Coding Agents Like a Pro. If you're on Copilot, see Using AI Agents in VS Code.

Sources

Originally published at papansarkar.com.

Use AI Coding Agents Like a Pro: Fewer Tokens, Better Code

Papan Sarkar — Sun, 01 Nov 2026 11:07:32 +0000

Most developers who complain that coding agents are expensive and sloppy are making the same mistake: they treat the agent like a chat window and let one session grow all day. In the 2025 Stack Overflow survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration. In my experience, "almost right" and "expensive" usually have the same root cause: too much of the wrong context.

This post is the workflow I use across Claude Code, OpenAI Codex, Cursor and GitHub Copilot. It is tool-agnostic on purpose. If you want the VS Code setup walkthrough, I covered that in Using AI Agents in VS Code. This one is about habits.

TL;DR

Context is the budget, not the prompt. Every turn re-sends the whole conversation, so a bloated session costs more and gets dumber at the same time.
One task per session. Clear between unrelated tasks. After two failed corrections, start over with a better prompt.
Keep your instruction file short. AGENTS.md / CLAUDE.md should hold only what the agent can't figure out from the code.
Give the agent a check it can run. Tests, a build, a linter. Without one, you are the test suite.
Push noisy work out of the main context. Subagents, filtered command output, CLI tools instead of piles of MCP servers.
Match the model and reasoning effort to the task. The biggest model on every typo fix is how bills explode.

Why context is the whole game

Three pieces of research explain almost every agent failure I see.

Performance drops as context grows. Chroma tested 18 models and found that "performance grows increasingly unreliable as input length grows," even on simple retrieval tasks (Chroma, Context Rot). In one test, models did much better on focused prompts of about 300 tokens than on the full 113k-token version (Chroma).

Position matters. The "Lost in the Middle" paper showed models use information at the start and end of a long context better than information buried in the middle (Liu et al., TACL). Your carefully written rule from 90 minutes ago is now in the middle.

Tokens are an attention budget. Anthropic's engineering team frames good context engineering as finding "the smallest possible set of high-signal tokens" that gets the result you want (Anthropic, Effective context engineering). Their Claude Code docs put it bluntly: the context window "is the most important resource to manage" (Claude Code best practices).

The cost side follows directly. Claude Code "sends your full conversation with every request," so a one-line question in a session open all day still pays for the whole history (Claude Code costs). Prompt caching softens this, since cache reads bill at a fraction of the normal input price (Anthropic prompt caching), but the cache has a lifetime. Come back after a break and you pay to reprocess everything.

Simple arithmetic: asking the same question in a fresh 20k-token session versus a stale 150k-token session is 7.5x the input tokens, and the stale session is more likely to answer wrong.

Do agents actually make you faster?

Short answer: yes for most people now, but not automatically. Here is the honest picture.

METR's randomised trial found experienced open-source developers took 19% longer with early-2025 AI tools, while believing they were 20% faster (METR, July 2025).
METR's follow-up says that result is now outdated and speedups "seem likely," but its new data is too biased by developers refusing to work without AI to give a reliable number (METR, February 2026).
Google's DORA 2025 report calls AI "an amplifier" of a team's existing strengths and weaknesses (DORA 2025). Throughput went up, but delivery instability kept rising (InfoQ on DORA 2025).
Trust is still low: 46% of developers distrust AI accuracy and only 33% trust it (Stack Overflow 2025).

My read: the gap between "agent made me slower" and "agent made me faster" is mostly workflow. The habits below are what close it.

Habit 1: Keep the instruction file short and boring

Every agent now reads a project instruction file: CLAUDE.md for Claude Code, AGENTS.md for Codex, Cursor and many others, .github/copilot-instructions.md for Copilot. AGENTS.md has become the shared format, now stewarded by the Agentic AI Foundation under the Linux Foundation (agents.md), and Copilot reads AGENTS.md and CLAUDE.md as well (GitHub Docs).

This file loads on every session, so every line is a recurring tax. All the vendors say the same thing:

Anthropic: "Aim to keep CLAUDE.md under 200 lines," and "Bloated CLAUDE.md files cause Claude to ignore your actual instructions!" (Claude Code costs, best practices)
OpenAI: "A short, accurate AGENTS.md is more useful than a long file full of vague rules" (Codex best practices).
Cursor: "Start simple. Add rules only when you notice Agent making the same mistake repeatedly" (Cursor rules).

The test for every line: would removing it cause a mistake? If not, cut it. Here is the shape I use for a Next.js + Node project:

# AGENTS.md

## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test one file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit
- Lint: pnpm lint

## Conventions the code won't tell you
- Server actions live in app/(actions)/, never inside components
- All DB access goes through lib/db/*.ts; no raw queries in routes
- Money is stored as integer paise, never floats

## Don't
- Don't edit files in migrations/ by hand; generate them
- Don't add dependencies without asking

## Done means
- Typecheck, lint and the relevant tests pass
- Show me the command output, not a summary of it

No "write clean code," no folder-by-folder tour, no API docs pasted in. The agent can read the code. Put workflow-specific knowledge (how to do a release, how to write a migration) in on-demand files: skills in Claude Code, "Apply Intelligently" or file-scoped rules in Cursor, task-specific markdown files referenced from AGENTS.md in Codex. Those load only when needed.

Habit 2: One task, one session

The most expensive pattern is what Anthropic calls "the kitchen sink session": you start one task, ask something unrelated, then go back (best practices). OpenAI says the same: "Keep one chat per coherent unit of work," because long single-project chats lead to "bloated context and worse results over time" (Codex best practices).

My rules:

New task, new session. In Claude Code, /clear costs nothing, while /compact reads the whole conversation to summarise it, so it is itself a large request (Claude Code costs).
Two strikes and restart. If I've corrected the agent twice on the same thing, the context is full of failed attempts. I clear and write a better first prompt that includes what I learned. Anthropic recommends exactly this (best practices).
Compact with instructions when you must keep going. /compact Focus on the API changes and the failing test keeps what matters instead of a generic summary.
Side questions go elsewhere. A quick "what does this flag do?" in the middle of a feature pollutes the context. Ask it in a separate window.

Habit 3: Plan only when the plan is worth it

Planning prevents the most expensive failure: a correct implementation of the wrong thing. Both Claude Code and Codex have a plan mode (Shift+Tab, or /plan in Codex) (Codex best practices).

But planning costs tokens too. Anthropic's rule of thumb is the best one I know: "If you could describe the diff in one sentence, skip the plan" (best practices).

Use a plan when the change touches several files, when you're unsure of the approach, or when you don't know this part of the codebase. For larger features, flip it around: have the agent interview you, write a SPEC.md, then start a fresh session to implement from the spec. The implementation session starts clean with a written contract instead of 40 turns of back-and-forth.

Habit 4: Write prompts with a "done when"

Vague prompts cause broad scanning, and scanning burns tokens. "Improve this codebase" makes the agent read everything; "add input validation to the login function in auth.ts" doesn't (Claude Code costs).

OpenAI's Codex guide recommends four parts: goal, context, constraints, and a "Done when" condition (Codex best practices). My template:

Goal: Users get logged out after a session timeout instead of a silent token refresh.
Context: Auth flow is in src/auth/. Token refresh is in src/auth/refresh.ts.
         Follow the error-handling pattern in src/auth/login.ts.
Constraints: No new dependencies. Don't change the public API of useSession().
Done when: A failing test reproduces the bug, the fix makes it pass,
           and `pnpm vitest run src/auth` plus `pnpm tsc --noEmit` are green.
           Paste the output.

Pointing to files with paths (or @file in Claude Code and Cursor) saves the agent from searching. Pointing to an existing pattern ("follow login.ts") gets you code that looks like the rest of your codebase instead of a generic tutorial.

Habit 5: Give the agent a check it can run

This is the single biggest quality lever. An agent "stops when the work looks done," and without a check it can run, you become the verification loop (best practices). With a test, build or linter, the agent runs it, reads the failure, and fixes it before you ever see the diff.

Three rules:

Ask for evidence, not claims. "Show the test output" beats "it should work now."
Run one test, not the suite. A full test run dumps thousands of lines of passing output into context. Point the agent at the relevant file.
Make the check deterministic when it matters. Claude Code hooks and Stop hooks run a script every time, unlike instructions in CLAUDE.md, which are advisory (best practices).

Habit 6: Keep noisy work out of the main context

Logs, test output, documentation pages and codebase exploration are the biggest context fillers. Three ways to keep them out:

Subagents for investigation. A subagent explores in its own context window and returns a summary, often 1,000-2,000 tokens (Anthropic, Effective context engineering). "Use a subagent to find how we handle token refresh and whether we already have OAuth utilities" keeps 30 file reads out of your implementation session. Note that subagents still cost tokens; they save context, and you can put them on a cheaper model.

Filter output before the agent sees it. Anthropic's example is a hook that greps a 10,000-line log for errors so the agent reads hundreds of tokens instead of tens of thousands (Claude Code costs). Even without hooks, you can just ask for it:

# Instead of letting the agent read the whole run:
pnpm vitest run 2>&1 | grep -E -A 5 '(FAIL|Error)' | head -80

Prefer CLI tools over stacks of MCP servers. Anthropic's own measurements show loading tool definitions and passing intermediate results through the model can be brutal: one workflow went from 150,000 tokens to 2,000 when the agent wrote code to call tools instead (Anthropic, Code execution with MCP). Claude Code now defers MCP tool definitions by default, but its docs still say CLIs like gh, aws and gcloud "are still more context-efficient than MCP servers" (Claude Code costs). Disable servers you aren't using in this task.

Habit 7: Match the model and effort to the task

Running the largest model at maximum reasoning on a rename is the fastest way to burn a budget. Prices differ a lot: on Anthropic's current list, Opus 5.5 output costs twice what Sonnet 5.5 does (Claude pricing), and Haiku 5.5 is far cheaper again (Claude pricing). Thinking tokens are billed as output tokens (Claude Code costs).

How I split it:

Task	Model tier	Reasoning effort
Rename, typo, add a log line, small CRUD endpoint	Mid or small	Low
Feature across 3-6 files with tests	Mid	Medium
Debugging a flaky race condition, architecture change	Top	High
Subagent doing file search or log summarising	Small	Low

OpenAI's Codex guidance lines up: low effort "for faster, well-scoped tasks," medium or high "for more complex changes or debugging," extra high for long, reasoning-heavy work (Codex best practices). In Claude Code, /model and /effort switch both mid-session (Claude Code costs).

Habit 8: Review with fresh eyes

An agent reviewing code it just wrote is biased toward its own reasoning. A reviewer in a fresh context sees only the diff and your criteria (best practices). I use a second session or subagent with a narrow brief: "Review this diff against SPEC.md. Report only gaps that affect correctness or stated requirements."

That last sentence matters. A reviewer asked to find problems will always find some, and chasing every nitpick leads to over-engineered code (best practices).

The token-waste cheat sheet

Symptom	Likely cause	Fix
Agent ignores a rule you wrote	Instruction file too long; rule lost in noise	Prune to essentials; move workflows to on-demand skills or rules
Usage spikes on a simple question	Session open for hours	`/clear` or a new chat per task
Same mistake after corrections	Context full of failed attempts	Restart with a better first prompt
Agent reads half the repo	Vague prompt	Name files, point to a pattern, add "done when"
Huge turns after running tests	Full test output in context	Run one file; filter to failures
Slow, pricey answers on easy tasks	Top model and max effort by default	Drop model tier and effort
"It works" but it doesn't	No runnable check	Require test or build output as evidence

When not to reach for an agent

You can't verify the result. If there's no test, no type system and no way to run it, a plausible diff is a liability.
The change is two lines you already know. Typing it is faster than writing the prompt.
The task is mostly a judgment call. Pricing logic, security boundaries, data deletion. Use the agent to explore options, then decide yourself.

The short version

Treat the agent like a strong engineer who forgets everything between sessions: short onboarding doc, one clear task, a definition of done, a test to run, and a fresh pair of eyes at the end. That is what uses fewer tokens, and it is also what produces code you can ship.

If you're planning a product and want someone who builds this way, I ship React/Next.js and Node.js products with AI in the loop for clients. Get in touch. If you're wiring LLMs into your own backend, start with my LLM integration guide.

Sources

Originally published at papansarkar.com.

LLM Prices Just Dropped Up to 80%: How to Re-plan Your App's AI Costs

Papan Sarkar — Fri, 30 Oct 2026 12:55:41 +0000

TL;DR: OpenAI and Anthropic have cut LLM prices by up to 80% since July 2026. Before you celebrate, check which line of your bill actually moved. For agent-style workloads, cached input dominates spend, small models now handle most "AI feature" work for pennies, and the safest architecture is one that lets you switch models with a config change. Here's how I'd re-plan an app's AI costs this week.

What changed

Max Woolf published a clear breakdown of the recent price cuts on 25 October. The short version:

OpenAI's small "Luna" tier dropped about 80% in July, then halved again with GPT-6 Luna in September.
Anthropic made a Sonnet 5 launch discount permanent, cut cache-read pricing hard on Fable 5.1, and cut Opus 5.5 by 40–60% overall compared to Opus 5.
OpenAI's flagship "Sol" models got cheaper in steps through August and September, with GPT-6.1 Sol halving cache reads again.

His explanation is competition: open-weight models and dozens of inference providers sell near-identical quality, so price is the lever left. Whatever the cause, it changes the maths for a lot of features that were "too expensive" in the spring.

But the headline number hides the part that matters for your app.

1. Find out which tokens you're actually paying for

Most of us look at the input and output price and stop there. The same write-up points out that in agentic coding, cache reads are 96–99% of token spend. Agents re-send the same system prompt, tool definitions and file context on every turn, and almost all of it is a cache hit.

So for an agent, a 75% cut on cache reads matters more than a 20% cut on output. For a one-shot summariser with no shared prefix, the reverse is true.

Before deciding anything, split your usage into those buckets. Both major APIs return usage per request. A tiny logger is enough to start:

// usage-log.ts
type Usage = {
  feature: string;
  model: string;
  inputTokens: number;
  outputTokens: number;
  cacheReadTokens: number;
  cacheWriteTokens: number;
};

export function logUsage(u: Usage) {
  // Swap console for your DB or analytics later.
  console.log(JSON.stringify({ ...u, at: new Date().toISOString() }));
}

Log it per feature, not just per model. "The AI bill" is useless. "The ticket-triage feature costs X per 1,000 tickets" is something you can make decisions about.

2. Structure prompts so the cache actually hits

If cache reads are now very cheap, the win is making sure your requests are cacheable in the first place. The rule is simple: stable content first, changing content last.

With Anthropic's Messages API, you mark the end of the stable prefix with cache_control:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

export async function answerWithDocs(docs: string, question: string) {
  return client.messages.create({
    model: process.env.LLM_MODEL!, // keep model IDs in config
    max_tokens: 1024,
    system: [
      { type: "text", text: "You answer questions using only the provided docs." },
      {
        type: "text",
        text: docs, // large, rarely changes -> cache it
        cache_control: { type: "ephemeral" },
      },
    ],
    messages: [{ role: "user", content: question }], // changes every call
  });
}

OpenAI applies prompt caching automatically on long prompts, but the same ordering rule applies: anything that changes per request (timestamps, user names, the question) belongs at the end. A single Today is ${new Date()} at the top of your system prompt quietly breaks the cache for everything after it.

Things that commonly bust the cache:

Dynamic values in the system prompt
Tool definitions generated in a different order each time
Re-serialising JSON context with unstable key order

3. Route by task, not by habit

Lots of products send everything to the flagship model because that's what the prototype used. Now the small tiers cost cents per million tokens, so it's worth being deliberate.

A simple router covers most apps:

// llm-router.ts
type Task = "classify" | "extract" | "summarize" | "reason" | "code";

const MODEL_FOR: Record<Task, string> = {
  classify: process.env.LLM_SMALL!,
  extract: process.env.LLM_SMALL!,
  summarize: process.env.LLM_SMALL!,
  reason: process.env.LLM_LARGE!,
  code: process.env.LLM_LARGE!,
};

export function pickModel(task: Task): string {
  return MODEL_FOR[task];
}

Then measure. Run a few hundred real inputs through the small model and compare with the large one on the cases you care about. If the small model is right often enough, ship it. If not, you've lost an afternoon, not a quarter.

I'd keep one honest caveat here: cheaper models are not automatically good enough. A specialised, boring approach (a regex, a classic classifier, a database query) still beats an LLM for plenty of tasks. Price cuts don't change that.

4. Put the provider behind one function

The other side of commoditisation: if quality is close and prices keep moving, switching providers becomes a normal operation. Make it cheap.

# llm.py
import os
from dataclasses import dataclass

@dataclass
class LLMResult:
    text: str
    input_tokens: int
    output_tokens: int

def complete(prompt: str, *, task: str) -> LLMResult:
    provider = os.environ["LLM_PROVIDER"]  # "anthropic" | "openai" | ...
    if provider == "anthropic":
        from .providers import anthropic_complete
        return anthropic_complete(prompt, task=task)
    if provider == "openai":
        from .providers import openai_complete
        return openai_complete(prompt, task=task)
    raise ValueError(f"Unknown provider: {provider}")

Nothing clever here, and that's the point. Your app code calls complete(). Model IDs, providers and fallbacks live in config. When the next price change lands, you change an environment variable and re-run your evals.

5. Re-check the features you shelved

This is where the price cuts can make actual product money. Go back through the AI ideas you dropped for cost and price each one at today's rates:

Question	Why it matters
Which tier does it really need?	Small-model pricing changes most features from "no" to "yes"
How much of the prompt is a stable prefix?	Cheap cache reads reward long, shared context
What does it cost per user per month?	Compare against what that user pays you
Does it still work at 2x today's price?	Prices can move in either direction

That last row is my rule of thumb. If a feature only makes sense at this quarter's prices, build it so you can swap models or switch it off without a migration. If it still makes sense at double the price, it's a real feature, so build it properly.

What I would not do

Don't jump to the most expensive model just because it's cheaper than last month. Measure first. Bigger isn't always better for narrow tasks.
Don't hard-code a model ID in twenty places. You will want to change it, probably soon.
Don't assume subscription plans follow API prices. Woolf notes he cut his own subscription quota, and he expects plan allowances may shrink before API prices rise.

Wrapping up

The price cuts are real, and they make a lot of AI features newly viable. The developers who benefit most will be the ones who know which tokens they pay for, keep their prompts cache-friendly, and can switch models without a rewrite.

Which line of your LLM bill surprised you most when you finally broke it down: input, output or cache?

I build web and AI products for clients; more about my work at papansarkar.com.

8 Habits to Stop Burning Tokens with AI Coding Tools

Papan Sarkar — Sun, 25 Oct 2026 00:45:16 +0000

Most developers burn AI tokens the same way they used to burn cloud credits: by not paying attention.

Every message you send to an AI coding tool also sends the context with it: the earlier chat history, the files it has read, and the tool output. When usage grows, it's rarely because of one huge prompt. It's because of context piling up quietly in the background.

Here are the habits that cut my usage the most without slowing me down.

1. One task per session

When a task is done, clear the context before you start the next one. A long chat re-sends old history with every turn, so you keep paying for a bug you fixed an hour ago.

In Claude Code, /clear does this. In other tools, just start a new chat.

2. Write a project rules file once

Put your stack, conventions, folder layout, and common commands in a rules file: CLAUDE.md for Claude Code, .cursorrules or project rules for Cursor, or your tool's equivalent.

Keep it short. It loads into every session, so a bloated rules file costs you tokens on every single request.

3. Point to files, don't paste them

Compare these two prompts:

"Fix the null check in auth/session.ts around line 40"
pastes three files "something's wrong with login"

The first one gives the agent a target. The second one invites it to explore.

4. Plan first, then execute

Ask for a short plan and approve it before the agent writes any code. Claude Code has a dedicated plan mode for this. A wrong direction caught at the plan stage costs a few hundred tokens. Caught after implementation, it costs you a full rewrite loop.

5. Match the model to the task

Renames, boilerplate, test scaffolding, and formatting don't need your most expensive model. Switch to a smaller or faster model for routine work, and save the big one for architecture decisions and hard debugging.

6. Give precise errors, not vibes

Paste the exact stack trace, the failing command, and what you expected to happen. "It's broken" makes the agent read through half your repo trying to reproduce the problem.

7. Keep noise out of reach

Build output, lockfiles, generated code, and large fixtures waste context when they get read. Cursor supports .cursorignore. In Claude Code, you can deny reads to specific paths in your settings permissions.

8. Summarize, then reset

When a session gets long but the work isn't finished, ask for a summary of the decisions made and the current state. Then start fresh and paste the summary in. Claude Code's /compact does a version of this for you.

The real point

Token efficiency isn't about being cheap. It's about context hygiene. A clean, focused context is cheaper, and it also gives you better output, because the model isn't sorting through stale or irrelevant information.

What's your biggest token-waster? Let me know in the comments.

How a Clean Next.js Repo Ran Malware on Every npm run dev

Papan Sarkar — Tue, 20 Oct 2026 21:44:19 +0000

A codebase I got through Fiverr looked like an ordinary Next.js invoice app. It wasn't.

Two dependencies deep, gated behind an npm auth token committed in the project's own .npmrc, sat a private package carrying roughly 180 KB of heavily obfuscated JavaScript — wired to execute every time the dev server starts.

I caught it before running it. Here is the short version.

Every standard check passed

package.json scripts held only dev, build, start and lint. No preinstall, no postinstall, no prepare.

A grep for the usual suspects came back empty:

grep -rnE "eval\(|new Function|child_process|execSync|spawn\(|atob\(|fromCharCode|base64" \
  --include=*.js --include=*.mjs --include=*.cjs --include=*.ts --include=*.jsx --include=*.tsx . \
  | grep -v node_modules

A long-line grep, which is how whitespace-padded payloads usually surface, matched only SVG path data and Tailwind class strings.

The repo was clean. The malicious code was never in it.

Three things that didn't add up

1. The project shipped an npm auth token.

$ cat .npmrc
//registry.npmjs.org/:_authToken=npm_HIswo…[redacted]

An npm access token carries "the right to install and/or publish your modules", including read access to private packages that account can see. A stranger's deliverable has no reason to include one. Its only function here was to let npm install fetch something you otherwise could not.

2. A Tailwind plugin I'd never heard of. devDependencies had "tailwind-animationlab": "^2.0.6". The real ones cluster around similar names — tailwindcss-animate, tailwindcss-animated, tailwind-animations. At the bottom of tailwind.config.js:

plugins: [
  require('tailwind-animationlab')({
    duration: '500ms',
    delay: '1s',
    iterationCount: '2'
  })
],

Nothing about that looks wrong — and that's the point. Tailwind's own docs register plugins exactly this way, with require() inside the plugins array. The config file was padded with friendly comments explaining unused theme values, which made one more require easy to skim past.

3. The timestamps. Nearly every file was dated Sep 13, 13:29. Three were not: .npmrc (Sep 13, 14:15), tailwind.config.js (Sep 28, 09:49), package.json (Sep 28, 09:50). Exactly the three files needed to authorize, inject and execute a dependency.

Following the chain

From my home directory, so the project's token wasn't picked up:

cd ~ && npm view tailwind-animationlab

One version, numbered 2.0.6 — new packages don't start at 2.0.6; it was chosen to satisfy the ^2.0.6 already in the project. Registry creation date 2026-09-28, the same day those config files were edited. npm maintainer adriannamrr, but author and homepage pointing at sericpieap. And one dependency I didn't recognise: @jasperquinn/postcss-motion-helpers.

I unpacked the decoy without executing it. Clean. It was built to survive a code review, because that's the layer a careful developer actually inspects.

Then:

npm view @jasperquinn/postcss-motion-helpers
# npm error 404 Not Found

A public package depending on a private one. Private npm packages "always have a scope" and are readable only by the owner and granted collaborators. So for anyone else on earth, installing tailwind-animationlab fails. It resolves only on a machine holding the attacker's token — which is to say, on a victim's machine, supplied through that .npmrc.

With the token, inside a throwaway Codespace on a burner GitHub account, still executing nothing, the private tarball's src/config.js was a wall of machine-generated obfuscation: an encoded blob, _0x hex identifiers, a large switch-based dispatch loop, heavy Proxy and Reflect use. A PostCSS helper has no reason to look like that.

Why `--ignore-scripts` wouldn't have helped

Most npm hardening advice is about install hooks. But npm's config reference is explicit that npm run and npm start "will still run their intended script if ignore-scripts is set" — they only skip pre- and post-scripts.

This attack never wanted an install hook. Tailwind v3 loads tailwind.config.js whenever it generates CSS, so that require() evaluates on every npm run dev and every npm run build. The trigger was the developer doing their job.

Same logic covers a neighbouring trick: VS Code's runOn: folderOpen means "the task will be run when the containing folder is opened". Clicking Trust on a stranger's folder is a code-execution decision.

Is this a known campaign?

The tradecraft matches Contagious Interview. Socket counted more than 338 malicious npm packages with over 50,000 cumulative downloads in a single wave, tied to more than 180 fake maintainer personas, attributed to "North Korean state-sponsored actors" — and its package list includes names impersonating tailwindcss, vite, eslint and next. Elastic documented a tampered Next.js e-commerce template carrying a credential and wallet stealer plus a Socket.IO RAT.

To be precise: I have not confirmed this sample is Contagious Interview. My delivery channel was a paid Fiverr gig, not a fake job interview, and I didn't reverse the payload. What matches is the playbook.

What I check now

ls -la — .npmrc with an _authToken, a custom registry=, a .vscode/tasks.json
scripts in every package.json, not just the root one
*.config.js for Tailwind, PostCSS, Next, ESLint, Vite — any require() you don't recognise
npm view <pkg> run from ~: single version, starting at 2.x+, published recently, maintainer ≠ author
npm view <pkg> dependencies: unknown scoped packages, or a 404 on the public registry
ls -la again, for a handful of config files edited separately from everything else

Two rules carry most of the weight: read unknown code in a disposable environment with no real credentials, and treat any .npmrc you didn't write as hostile.

Status as of writing

I reported both packages and both maintainer accounts to npm, the seller to Fiverr, and the GitHub account to GitHub. The sericpieap GitHub account and its homepage now return 404. But tailwind-animationlab@2.0.6 is still installable from the public registry, and @jasperquinn/postcss-motion-helpers still 404s publicly — the delivery mechanism is intact.

Indicators: tailwind-animationlab@2.0.6, shasum 9636e080056e59024e3e0d70f998d8f80e9129a9, maintainer adriannamrr, author/homepage sericpieap, created 2026-09-28. Private dependency @jasperquinn/postcss-motion-helpers@1.0.3, referenced as ^1.0.1.

If you've seen these package names in a dataset, I'd like to hear about it.

Prototyping just went from "Hours" to "Minutes." ⚡️

Papan Sarkar — Fri, 05 Dec 2025 17:19:32 +0000

I remember when setting up a clean, responsive dashboard meant wrestling with boilerplate code for half a day.

Today, I challenged Google AI Studio to build a fully functional Personal Finance Dashboard using React, Tailwind CSS, and Recharts.

The result? A stunning, dark-mode UI with "Bento Grid" layout and glassmorphism effects—generated in under 120 seconds. 🤯

Why this matters for developers: It's not about AI replacing us. It's about "Velocity to V1." Instead of spending 4 hours on the UI shell, you spend 2 minutes generating it, and the next 3 hours and 58 minutes on the actual logic and backend architecture.

The Reality Check: Yes, this is a frontend prototype. It still needs a secure backend, auth, and database. But the visual heavy lifting? Done.

I shared the full breakdown and code in my latest YouTube Short.

What you see here is a Frontend Prototype (the interface). It looks great, but to turn this into a real, working app, you still need: A Backend (Logic to handle transactions). A Database (To actually save user data). Authentication (Secure login/signup).

The Reality: AI is an amazing tool to speed up the design and boilerplate code, but you still need to understand programming to connect the pieces and make it secure! Use this to prototype fast, not to skip learning the basics.

🚀 Need to turn your idea into a working product fast? Check out how we build high-performance MVPs at Yestoideas

🚀 Supabase Connection Scaling: The Essential Guide for FastAPI Developers

Papan Sarkar — Fri, 14 Nov 2025 18:24:55 +0000

Building a scalable FastAPI backend requires mastering database connections. When using Supabase (PostgreSQL), choosing the wrong connection method is the fastest way to crash your server under load. This guide clarifies the critical difference between Transaction Mode and Session Mode to help you choose the right path for high performance.

🔒 The Connection Pooler: Your Database’s Gatekeeper

Every Supabase project includes a Connection Pooler (Supavisor/PgBouncer). Its job is to efficiently manage traffic between your many client applications and your limited database resources.

The “Lobby” (Max Client Connections): This is the high limit (e.g., 200 on Nano). It’s the total number of clients that can connect to the pooler.
The “Tellers” (Pool Size / Backend Connections): This is the low, resource-intensive limit (e.g., 15–20 on Nano). It’s the number of actual PostgreSQL processes available to run queries.

The core challenge is enabling hundreds of clients in the Lobby to efficiently share just 20 Tellers.

1. Transaction Mode: Lightning-Fast Exchange (Port 6543) ⚡

Transaction Mode is the mandatory choice for scalable, high-concurrency web APIs.

How it Works: A client (your FastAPI endpoint) borrows a Teller only for the duration of a single transaction or query. The moment the transaction commits, the Teller is immediately released back to the pool for the next waiting client.
Analogy: The Express Lane at a bank. You quickly finish your one task, and the Teller is free instantly.
Advantages: Maximizes throughput and concurrency. A few connections can handle a high volume of requests because no connection is ever held idle.
When to Use: Default mode for all general-purpose web traffic, serverless functions, and short-lived tasks.
Supabase Port: 6543.

2. Session Mode: The Dedicated Teller (Port 5432) 🔑

Session Mode is a stateful mode designed for compatibility and long-running tasks.

How it Works: A client connection permanently holds a specific backend connection (Teller) for the entire duration of the client’s session, even when the client is idle. The connection is only returned when the client disconnects.
Analogy: The Personal Banker. You keep the banker until your entire long meeting is over, making them unavailable to others.
Advantages: Provides Full PostgreSQL Compatibility for features that require persistent state.
When to Use: Database migrations, admin tools, debugging, or complex background jobs that rely on setting session variables (SET TIME ZONE) or using temporary tables.
Supabase Port: 5432 (the default PostgreSQL port).

🛑 The Critical Pitfall: Running FastAPI in Session Mode

If your FastAPI backend connects on Port 5432, your entire application operates in Session Mode, leading to three major stability risks:

Rapid Limit Exhaustion: Your application effectively ignores the 200 client limit and is capped by the 20 Pool Size. If 21 instances or users connect, the 21st is blocked, even if the first 20 are idle.
Memory Overload: Holding 20+ persistent connections on a small instance (like Nano) quickly exhausts the server’s limited RAM, forcing the database into a read-only state to prevent a crash.
Connection Leakage: Any connection not cleanly closed by FastAPI will remain stuck, eventually using up all 20 backend connections permanently.

🛠️ The Essential Code Fix: Disable Prepared Statements

The migration to Transaction Mode (Port 6543) requires a vital code change because it breaks a common optimization feature: Prepared Statements.

The Conflict: Prepared statements are an efficiency feature that involves storing a pre-compiled query plan on a specific session (backend connection). When Transaction Mode swaps the connection, the new connection cannot find the stored plan, causing the frequent and fatal prepared statement “…” does not exist error.
The Solution: You must configure your Python database driver or ORM (like SQLAlchemy with asyncpg) to explicitly disable prepared statements by setting the cache size to zero.

Python/FastAPI Configuration (SQLAlchemy + Asyncpg)

This code snippet is the necessary modification when pointing your FastAPI backend to Port 6543.

from sqlalchemy.ext.asyncio import create_async_engine
from sqlalchemy.pool import NullPool 

# ⚠️ Change port to 6543
DATABASE_URL = "postgresql+asyncpg://user:pass@host.supabase.co:6543/postgres" 

engine = create_async_engine(
    DATABASE_URL,
    # Use NullPool: Let the external pooler (Supavisor) manage connections, not the app.
    poolclass=NullPool, 
    connect_args={
        # CRITICAL: Disables statement caching, fixing the Transaction Mode conflict
        "statement_cache_size": 0, 

        # Ensures asyncpg also respects the cache being disabled
        "prepared_statement_cache_size": 0, 
    },
)

Note: If using the pure psycopg3 driver, you would typically pass prepare_threshold=None to the connection pool configuration.
Conclusion

For a scalable FastAPI application on Supabase, always start with Transaction Mode (Port 6543) as your default for all API traffic. This choice maximizes concurrency and efficiency. Reserve Session Mode (Port 5432) only for specialized, stateful tasks like migrations or admin scripts. The main takeaway: Enable Port 6543 and disable prepared statements to unlock optimal scalability and prevent stability issues.

Dynamic Serializers in Django

Papan Sarkar — Wed, 17 Apr 2024 18:24:08 +0000

Dynamic serializers are extremely useful to make flexible APIs.

Why do we need dynamic serializers

Flexibility: It provides flexibility. We often run into issues, where we need a serializer but not all the fields from that serializer. In that case dynamic serializers are especially useful to use subsets of data.

Code Reusability: No need to write multiple serializers anymore, a single dynamic serializer can achieve various needs.

Performance: If we only pick the fields we need, it will immensely improve the overall performance.

While it has good advantages, it comes with few complexities as well. It can make debugging a little difficult and we can come across with errors if we do not follow good practices and test all kind of edge cases.

Implementation:

class DynamicSerializer(ModelSerializer): 

    """
    A ModelSerializer that takes an additional 'fields' 
    argument that controls which fields should be displayed. 
    """


    def __init__(self, *args, **kwargs): 

        fields = kwargs.pop('fields', None) 

        # Instantiate the superclass normally 

        super(DynamicFieldsModelSerializer, self).__init__(*args, **kwargs) 

        if fields is not None: 

            # Drop any fields that are not specified in the `fields` argument. 

            allowed = set(fields) 
            existing = set(self.fields.keys()) 
            for field_name in existing - allowed: 
                self.fields.pop(field_name)


# Example usage in a view 
class UserSerializer(DynamicFieldsModelSerializer): 
    class Meta: 
        model = User 
        fields = '__all__' `


# In your view 
serializer = UserSerializer(user, fields=('id', 'username', 'email'))

Conclusion:

Dynamic serializer is powerful tool in Django, especially for large and complex projects.

Proper implementation and thorough testing are important to achieve good and optimised results.

Don't write queries inside serializers in Django!

Papan Sarkar — Sat, 13 Apr 2024 14:36:06 +0000

Why?

It should focus data conversion and validations only. Don't write database logic on this.
Not efficient and bad performance. It will create lots of queries
You can not reuse it
Very hard to test
Readability is gone

I can share the alternatives if you want! Let me know

Do's and Don'ts in Django

Papan Sarkar — Fri, 12 Apr 2024 17:34:42 +0000

Do’s

Use meaningful variables: We should use clear, concise, and self-explanatory variables, functions, and classes name.

DRY: Don’t Repeat Yourself. We should reuse code as much as possible. Once you are done with the code, take 10 minutes to think what the possibilities are to improve it further and make it optimal.

Use Django features: On daily basis, we receive unique requirements which is consist of unique business logic for those cases we often write flexible code to solve a problem, which is fine but again it might not be the optimal solution. So again, take 10 minutes extra to research how could you have done this differently keeping a standard approach and solution.

Quick related note: It is very normal to think of a custom solution first, however it helps or comes to your head. No one solves a problem in the first go with the best possible solution and standards. It is always the next set of iteration which makes the difference.

Do a security check: Always do a security check once you are done with a task. Think of edge cases which can eventually create a problem. If needed get on a call with someone and share your thoughts and understanding, you will get more clarity with another set of eyes.

Follow PEP8: Since so many people are working on the same code, and we are trying to make it more readable and understandable. It is especially important that we make use PEP 8 style guide for Python code.

Don’ts

Do not write Complex Queries on serializers: Avoid writing complex queries on serializers or any serializer methods. Prefetch data in views instead.

Don’t write generic views all the time: Generic views are super useful and powerful but do not use it when it is not required. If the requirement is simple and straightforward write Functional views instead.

**Don’t keep unlimited access to endpoints (Rate Limiting): **Implement rate limiting to protect APIs.

Don’t write nested serializers: Nested serializers can produce inefficient queries and effect performance. Create different endpoints for these cases or change the data structure.

Don’t write business logic inside views or serializers: It is one of most important things to consider when building a huge project consists of lots of business logic. Business logic should be written in service layer, model property methods etc.

Take a Ten Minute Walk: A Codewars kata solution By Papan Sarkar

Papan Sarkar — Wed, 07 Oct 2020 08:41:24 +0000

Take a Ten Minute Walk: A Codewars kata solution
In this article, I'll explain a kata solution from Codewars. This kata(problem) is authored by JKphobic. And here is the kata
link:https://www.codewars.com/kata/54da539698b8a2ad76000228/train/python

Problem:
You live in the city of Cartesian where all roads are laid out in a perfect grid. You arrived ten minutes too early to an appointment, so you decided to take the opportunity to go for a short walk. The city provides its citizens with a Walk Generating App on their phones -- every time you press the button it sends you an array of one-letter strings representing directions to walk (eg. ['n', 's', 'w', 'e']). You always walk only a single block for each letter (direction) and you know it takes you one minute to traverse one city block, so create a function that will return true if the walk the app gives you will take you exactly ten minutes (you don't want to be early or late!) and will, of course, return you to your starting point. Return false otherwise.

Note: you will always receive a valid array containing a random assortment of direction letters ('n', 's', 'e', or 'w' only). It will never give you an empty array (that's not a walk, that's standing still!).

First of all, we need to understand the problem. Then we will see what it's input and of course what kind of output it wants from us.

If you read the problem twice or thrice, you'll see a few things like what things we need to keep in our minds. Like :

The walk has to be for 10 minutes.
You need to return to the starting point
Every list item (each letter) or single block represents one minute

Let's convert these instructions into code and make small segments of the whole solution code:
So,

if len(walk) == 10 //True
else // False

We'll create two variable and initialize to 0 to track our walk, ns (North-South) and ew (East-West) -

ns = 0
ew = 0

For every single block we walk, respectively we'll increment and decrement with 1

if we move in n direction then ns += 1
if we move in s direction (coming back) then ns -= 1
if we move in e direction then ew += 1
if we move in w direction (coming back) then ew -= 1

And then finally we will check we returned to our same position or not

if ns == 0 and ew == 0 //True
else //False

Let's combine all this:

# Python Solution
def is_valid_walk(walk):
    ns, ew = 0, 0
    if len(walk) == 10:
        for i in walk:
            if i == 'n': ns+=1
            if i == 's': ns-=1
            if i == 'w': ew+=1
            if i == 'e': ew-=1
    else:
        return False
    return ns == 0 and ew == 0

//Javascript solution
function isValidWalk(walk) {
    let ns = 0, ew = 0; 
    if(walk.length === 10){
      for (let i of walk) { 
        if (i == 'n') ns += 1; 
        if (i == 's') ns -= 1; 
        if (i == 'e') ew += 1; 
        if (i == 'w') ew -= 1; 
      } 
    }
    else
      return false
      return ns === 0 && ew === 0; 
  }

Now it's time to some other best and clever solutions:
Most upvoted:

def isValidWalk(walk):
    return len(walk) == 10 and walk.count('n') == walk.count('s') and walk.count('e') == walk.count('w')

Second one:
def isValidWalk(walk):
    if (walk.count('n') == walk.count('s') and 
        walk.count('e') == walk.count('w') and
        len(walk) == 10):
            return True
    return False

I hope it was helpful and useful. Please let me know your thoughts. Thank You for reading.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler

DEV Community: Papan Sarkar

The AI Productivity Paradox: More Starts, Fewer Finishes

TL;DR

Why does AI make developers busier instead of freer?

What the research says about AI and workload

The case that this is fine

It's a management problem, not a tooling one

Rule 1: One thing in progress per product

Rule 2: A written "done" before any code

Rule 3: A weekly look at what you started and should kill

Before you start the next thing

The short version

Sources

Claude Code vs Codex: How I Use Both on One Repo

TL;DR

Claude Code vs Codex at a glance

Both are safe bets now

Where Claude Code wins for me

Where Codex wins for me

One AGENTS.md for both agents

The loop: one agent writes, the other reviews

Which agent for which job

What running both costs

When I don't bother with two agents

The short version

Sources

Use AI Coding Agents Like a Pro: Fewer Tokens, Better Code

TL;DR

Why context is the whole game

Do agents actually make you faster?

Habit 1: Keep the instruction file short and boring

Habit 2: One task, one session

Habit 3: Plan only when the plan is worth it

Habit 4: Write prompts with a "done when"

Habit 5: Give the agent a check it can run

Habit 6: Keep noisy work out of the main context

Habit 7: Match the model and effort to the task

Habit 8: Review with fresh eyes

The token-waste cheat sheet

When not to reach for an agent

The short version

Sources

LLM Prices Just Dropped Up to 80%: How to Re-plan Your App's AI Costs

What changed

1. Find out which tokens you're actually paying for

2. Structure prompts so the cache actually hits

3. Route by task, not by habit

4. Put the provider behind one function

5. Re-check the features you shelved

What I would not do

Wrapping up

8 Habits to Stop Burning Tokens with AI Coding Tools

1. One task per session

2. Write a project rules file once

3. Point to files, don't paste them

4. Plan first, then execute

5. Match the model to the task

6. Give precise errors, not vibes

7. Keep noise out of reach

8. Summarize, then reset

The real point

How a Clean Next.js Repo Ran Malware on Every npm run dev

Every standard check passed

Three things that didn't add up

Following the chain

Why --ignore-scripts wouldn't have helped

Is this a known campaign?

What I check now

Status as of writing

Prototyping just went from "Hours" to "Minutes." ⚡️

🚀 Supabase Connection Scaling: The Essential Guide for FastAPI Developers

🔒 The Connection Pooler: Your Database’s Gatekeeper

1. Transaction Mode: Lightning-Fast Exchange (Port 6543) ⚡

2. Session Mode: The Dedicated Teller (Port 5432) 🔑

🛑 The Critical Pitfall: Running FastAPI in Session Mode

🛠️ The Essential Code Fix: Disable Prepared Statements

Dynamic Serializers in Django

Don't write queries inside serializers in Django!

Do's and Don'ts in Django

Do’s

Why `--ignore-scripts` wouldn't have helped