DEV Community: Diven Rastdus

5 New Postgres 19 Features in 2026 (And 2 That Got Pulled Before Release)

Diven Rastdus — Mon, 28 Sep 2026 10:12:38 +0000

If you read a "what's new in Postgres 19" post this summer, two of its headline features are gone. SQL/PGQ graph queries and FOR PORTION OF temporal updates were both reverted in September, weeks before release. Beta 4 shipped on September 24, the release candidate is due in early October, and GA may follow the same month. Here's what actually made it, the five I'd use in an app: INSERT ... ON CONFLICT DO SELECT, IGNORE NULLS in window functions, WAIT FOR LSN, REPACK CONCURRENTLY, and pg_plan_advice.

I run a handful of consumer apps on hosted Postgres. Every supabase/config.toml I own still says major_version = 17, a year after Postgres 18 went GA, because Supabase's 18 rollout is still not done. RDS had 18 within seven weeks and Neon had a preview the next day, so your lag depends on your host. For a lot of us a "what's new in 19" post is really a "what to plan for" post. I read the release notes and all four beta announcements so you can skim this instead.

1. INSERT ... ON CONFLICT DO SELECT ends the get-or-create dance

You can now insert a row or fetch the existing one in a single atomic statement, and RETURNING hands you the row either way. Before 19, "get or create" meant one of two hacks. Either a fake update (DO UPDATE SET id = excluded.id) that wrote WAL and left a dead tuple behind for nothing, or two round trips with a race between them.

INSERT INTO profiles (user_id, plan)
VALUES ($1, 'free')
ON CONFLICT (user_id) DO SELECT
RETURNING *;

Three rules from the INSERT docs. RETURNING is mandatory, unlike DO NOTHING and DO UPDATE. A conflict target is mandatory. You need SELECT privilege on the table. You can also add DO SELECT FOR UPDATE to lock the existing row, which is what you want when the next statement modifies it. That variant also needs UPDATE privilege on at least one column.

Someone will suggest the CTE: WITH ins AS (INSERT ... ON CONFLICT DO NOTHING RETURNING *) SELECT * FROM ins UNION ALL SELECT .... That races too. A row committed by another session after your snapshot started isn't visible to the fallback SELECT, so under load you get zero rows back. DO SELECT reads the conflicting row directly.

My signup trigger does insert into profiles ... on conflict (id) do nothing. When the row already exists, DO NOTHING returns nothing, so every caller that needs the row does a second SELECT. In 19 that's one honest statement.

2. IGNORE NULLS finally works in window functions

"Carry forward the last non-null value" no longer needs a self-join, a correlated subquery, or a custom aggregate. Postgres 19 adds the SQL-standard null treatment clause to lag, lead, first_value, last_value, and nth_value. The default stays RESPECT NULLS, so nothing changes until you ask.

SELECT day,
       last_value(price) IGNORE NULLS OVER (
         ORDER BY day
         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
       ) AS price_filled
FROM daily_prices;

Oracle, Snowflake, and DuckDB have had this for years. It matters for any sparse time series: sensor readings, price ticks, feature flags that only log changes. Mood trackers are the classic case. People skip logging on weekends, and every chart wants the last known value carried forward.

3. WAIT FOR LSN gives you read-your-writes on a replica

After a write on the primary, capture the write-ahead log position, then make the replica wait for it before you read. The classic bug this kills: a user saves, the page reloads, the read hits a replica that is 40 ms behind, and the user sees their old data.

-- On the primary, right after the commit
SELECT pg_current_wal_insert_lsn();
-- 0/0306EE20

-- On the replica, before the read
WAIT FOR LSN '0/0306EE20' WITH (TIMEOUT '200ms', NO_THROW);
SELECT * FROM orders WHERE user_id = $1;

Stash the LSN from the write response in the session or a cookie, and send it with the next read. WAIT FOR returns success, timeout, or not in recovery, so your app can fall back to the primary when the replica is too far behind. Restrictions worth knowing: it must be a top-level command (no functions or DO blocks), and it has to be the first statement of a transaction or run outside one. It is also rejected outright if your session already holds a lock and the target LSN hasn't arrived. The MODE option picks what you wait for. standby_replay is the default and the one that gives you read-your-writes. standby_flush waits only until the WAL is durable on the replica, and standby_write only until it is received.

4. REPACK CONCURRENTLY rebuilds a bloated table without the long lock

REPACK unifies VACUUM FULL and CLUSTER into one command (the old ones stay for compatibility), and CONCURRENTLY takes the ACCESS EXCLUSIVE lock only for the final file swap. Under the hood it uses logical decoding to capture the writes that land during the rebuild and applies them before the swap. It's pg_repack, in core.

REPACK (CONCURRENTLY, VERBOSE) events USING INDEX events_created_at_idx;

Read the caveats before you run it on a hot table. The docs say plainly that REPACK CONCURRENTLY is not MVCC-safe. It needs free disk at least equal to the table plus its indexes, and a bit more to buffer the concurrent writes. The table needs a primary key or an index-based replica identity, and it can't be partitioned, unlogged, or a materialized view. It can't run inside a transaction block, DDL on the table from another session can make it fail, and you need the MAINTAIN privilege. VACUUM FULL blocks reads and writes for the entire rewrite, which on a 50 GB events table is a very long outage. I'd upgrade for this alone.

5. pg_plan_advice: plan hints, the sanctioned kind

Postgres has resisted Oracle-style query hints for about twenty years. pg_plan_advice is the closest thing now in contrib. It's a loadable module that prints the advice string reproducing the plan you have. Set that string and the planner is steered toward that plan while you fix the real cause.

LOAD 'pg_plan_advice';

EXPLAIN (COSTS OFF, PLAN_ADVICE)
SELECT * FROM orders o JOIN customers c ON c.id = o.customer_id;
-- the plan output now includes the advice that reproduces it

SET pg_plan_advice.advice = 'JOIN_ORDER(o c) HASH_JOIN(c)';

The advice vocabulary covers join order, join method, scan method, and parallelism: JOIN_ORDER, HASH_JOIN, NESTED_LOOP_PLAIN, SEQ_SCAN, INDEX_SCAN, NO_GATHER. Two honest limits. Advice can only pick among plans the planner already considers, and a SET only affects your own session. For the app's connections you either apply it with ALTER DATABASE ... SET pg_plan_advice.advice = ..., or use the companion pg_stash_advice extension, which stores advice per query id and applies it automatically. Turn on pg_plan_advice.feedback_warnings and the planner tells you when it couldn't follow your advice. The 3 a.m. use case is a plan that flips after an ANALYZE on a table that just crossed a size threshold. Stash it, page nobody, fix the statistics in the morning.

The 2 that got pulled before release

SQL/PGQ graph queries (reverted September 7)

Beta 1 shipped CREATE PROPERTY GRAPH and GRAPH_TABLE, the SQL:2023 way to run graph queries over ordinary tables. Friends-of-friends, dependency chains, and permission graphs in plain SQL with no Neo4j. It was reverted by its own committer, Peter Eisentraut, with unresolved problems: DROP TABLE ... CASCADE left orphaned graph metadata, label scoping was wrong, and pg_dump hit dependency loops with materialized views that queried GRAPH_TABLE. Tom Lane's take on the risk: "I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20." The earliest it can return is Postgres 20, expected around September 2027.

FOR PORTION OF temporal updates (reverted September 15)

UPDATE prices FOR PORTION OF valid_range FROM '2026-07-01' TO '2026-10-01' SET price = 34.99 would have split a row automatically and completed the SQL:2011 temporal feature set. It was pulled for a concurrency anomaly at READ COMMITTED, the default isolation level. Two sessions updating overlapping ranges could leave the second one silently updating zero rows. The feature's own documentation described the problem and prescribed an explicit row lock as the workaround, and the community chose to revert rather than ship with a footnote. Dimitri Fontaine has the full walkthrough.

Also pulled this cycle: GROUP BY ALL (reverted in July, listed in the Beta 3 notes), ALTER TABLE ... MERGE/SPLIT PARTITIONS (August 27, the second time it has been pulled before release, after Postgres 17 in 2024), and online data checksums (September 16). Five feature reverts in one beta cycle is unusual, and I read it as the project protecting its five-year support promise.

Defaults that change under you

None of these need new SQL. All of them can surprise you on upgrade day. Every one is listed in the migration section of the release notes.

JIT is off by default. If a reporting query got faster from JIT, it gets slower again unless you turn it back on.
max_locks_per_transaction doubles from 64 to 128. An explicit setting keeps your old value, so check your config.
log_lock_waits is on by default. Expect more log volume on a contended database.
default_toast_compression becomes lz4. Faster, slightly larger, and it only affects newly compressed values. Existing TOAST data stays as it is.
RADIUS authentication is gone and md5 logins now warn on every successful login. Move to scram-sha-256.
standard_conforming_strings can no longer be turned off. Old dumps that relied on it won't load.
btree_gist indexes on inet and cidr are flagged as broken. GiST is the new default opclass for those types. pg_upgrade disallows any cluster that still has one of the old indexes, so rebuild them first.
json_array() over zero rows returns [], not NULL. Any IS NULL check or coalesce on that result changes behavior silently.
Database, role, and tablespace names can't contain a carriage return or line feed. pg_upgrade rejects them, so rename first.

What to do this week

If you're on Supabase you probably won't run 19 in production before well into 2027. On RDS or Neon it could arrive within weeks of GA. Either way, you can prep now. Diff the defaults list against your postgresql.conf, because every one of them is a config change you can stage in advance. Then find your get-or-create paths and your fill-forward queries and mark them, because those are the first two things to rewrite the day your host offers 19. And try ON CONFLICT DO SELECT against a copy of your schema on the beta, not in production:

docker run -d --name pg19 -e POSTGRES_PASSWORD=pg -p 5433:5432 postgres:19beta4
psql -h localhost -p 5433 -U postgres

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

How to Give Your App a Review Monitor That Actually Works (Google Play and App Store, Only New Reviews)

Diven Rastdus — Thu, 24 Sep 2026 17:07:01 +0000

A review monitor that actually works has four parts: a public source for each store, a stable review ID to de-duplicate on, a memory of what it already sent you, and a delivery channel that isn't your inbox. Get those four right and "only the new reviews, both stores, no server" is a daily schedule, not a project. Most review scrapers get one of them wrong, usually the memory, so they hand you the same 200 reviews every morning and you stop reading.

Why the stores' own tools are not enough

The stores tell you about reviews late, partially, or only for apps you own. Google Play's Developer API returns reviews for your own apps only, and only the ones with text from roughly the last week. Apple's App Store Connect API needs your own keys and never covers a competitor. If you want "every new review on both stores, mine and the two apps I compete with, the morning it lands", nothing in the consoles does it.

I ship three Android apps, and a review is usually the first signal that something broke or that a feature is wanted. A five-star review on one of them asked for a date-format setting, and it shipped in the next release. A three-star "It doesn't work sometimes" on another was the first report of a bug. The gap between "a review landed" and "a human read it" is the whole problem.

Part 1: where the reviews actually come from

Both stores expose public review data, just not through an API you'd enjoy. Google Play has no public reviews API at all. The store page loads its reviews through an internal batchexecute endpoint, which is what every Play scraper on npm calls under the hood (google-play-scraper is the well-known one). Apple is friendlier. There is a public RSS feed per app and country, newest first:

https://itunes.apple.com/us/rss/customerreviews/page=1/id=324684580/sortby=mostrecent/json

It serves at most 10 pages of 50 reviews, so 500 per app per country, and it carries no developer replies. Google Play does carry replies, and it dropped review titles years ago, so title is always null there. Your normalized row has to accept both shapes:

{
  "store": "google-play",
  "appId": "dev.astraedus.nudge",
  "country": "us",
  "reviewId": "6ca5d4fd-5ef6-49bc-877e-159f062a5a91",
  "rating": 3,
  "title": null,
  "text": "It doesn't work sometimes",
  "date": "2026-09-06T09:09:52.941Z",
  "appVersion": "1.15.2",
  "developerReply": null,
  "isNew": true
}

Part 2: the de-duplication key is the whole product

The review ID is the only stable thing. Both stores give every review an ID that survives edits, rating changes and re-sorting, so "new" means "an ID I haven't emitted before", never "dated after my last run". Dates fail in two ways: users edit old reviews (new date, same review), and stores serve pages out of order under load. Keep a set of emitted IDs per app and country, and diff against it:

// state key: `${store}:${appId}:${country}` -> string[] of emitted review IDs
async function newReviews(key: string, fetched: Review[], store: KVStore) {
  const seen = new Set<string>((await store.get(key)) ?? []);
  const fresh = fetched.filter((r) => !seen.has(r.reviewId));
  await store.set(key, [...seen, ...fresh.map((r) => r.reviewId)]);
  return fresh; // first run: the backlog; every run after: only the delta
}

The first run per app is the baseline, so cap it (200 is plenty). Every later run returns only the delta, which is what makes a daily digest readable.

Part 3: don't believe an empty answer

"No new reviews" and "the store wouldn't serve the feed" look identical unless you check. Apple's public feed periodically answers 200 OK with zero reviews for every app, which is rate limiting wearing a valid response. Recording that as "nothing new" costs you nothing in data, since the IDs were never emitted. It costs you the truth: the monitor now believes it looked when it didn't. The cheap guard is to cross-check the app's public rating count: an app with 4,000 ratings and an empty feed is a store problem, not a quiet week. Log three different empties, and never collapse them into one:

this app has no reviews yet
this app ID doesn't exist in this storefront
the store declined right now, retry later

Never tell yourself "no new reviews" when the truth is "we could not look".

Part 4: deliver to a webhook, not a dashboard

A monitor you have to open is a dashboard, and dashboards don't get opened. Post one JSON summary per run to a webhook and let Slack, Telegram, Zapier or n8n do the rest:

{
  "runAt": "2026-09-24T08:00:00.000Z",
  "totals": { "appsChecked": 5, "newReviews": 3, "errors": 0 },
  "apps": [
    {
      "store": "google-play",
      "appId": "com.example.app",
      "newCount": 2,
      "avgRating": 3.4,
      "lowestReviews": [{ "rating": 1, "text": "Crashes on launch", "url": "https://play.google.com/store/apps/details?id=com.example.app" }]
    }
  ]
}

Filter before you post. Alerting only on ratings of 2 and below means every message is worth reading, and a webhook that's down should be logged and ignored, never allowed to fail a run.

Running it daily with no server

The scheduler is the only part that has to live somewhere other than your laptop, and a GitHub Actions cron is free. A workflow on a daily schedule, google-play-scraper plus the Apple feed, and a committed seen.json as the ID set is about a hundred lines. Commit the state file back at the end of the run and your memory survives the ephemeral runner, which is the only trick in it:

on:
  schedule:
    - cron: "0 8 * * *"
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: node monitor.js
      - run: |
          git config user.name github-actions
          git commit -am "reviews: update seen set" || exit 0
          git push

I also packaged the four parts as an Apify actor, App Store and Google Play Review Monitor, if you'd rather not own the cron. Same four parts, same empty-feed guard, pay-per-event, a couple of dollars a month at five apps.

The takeaway

The hard part of a review monitor is not fetching reviews. It's remembering what you already saw and refusing to trust an empty page. Build the memory around review IDs, treat "no reviews" as a claim to verify, and push the result somewhere you already look. Then the monitor keeps working on the day you stop thinking about it, which is the only day that matters.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

TypeScript vs JSDoc vs JavaScript: Which Should You Use in 2026

Diven Rastdus — Mon, 21 Sep 2026 10:12:22 +0000

Use TypeScript for anything that another file, another person, or an AI agent will import. Use plain JavaScript for the rest. JSDoc with // @ts-check covers the ground in between. That's the whole answer. It's a cleaner answer in 2026 than it was, because both classic objections to TypeScript are dead. Node runs .ts files directly, so there's no build step. TypeScript 7 shipped in July as a native Go port, so the compiler is about ten times faster. What's left is a judgement about boundaries, not about tooling.

I ship both languages, sometimes in the same repository. Three sibling Apify actors live in one monorepo. One is strict TypeScript with noUncheckedIndexedAccess on, one is strict TypeScript with it off, and one is 22 files of plain JavaScript. None of that was taste. Each one got the amount of checking its data earns. Here's the rule I use, and the 2026 facts that make it hold.

What changed in 2026?

The cost side of the TypeScript trade collapsed. Three releases did it, and the last two landed this year.

TypeScript 6.0 shipped in March as the last release built on the JavaScript codebase. It turned strict on by default and started retiring target: es5 along with the AMD and UMD module formats. Start a project today and you get strict mode without asking for it.

TypeScript 7.0 shipped on July 8 as the native Go port, the one that spent a year as "Project Corsa". Microsoft's numbers on real repositories: VS Code type-checks 11.9x faster, Sentry 8.9x, Playwright 8.7x. A check that took a minute now takes seconds. The catch as of 7.0 is that the stable programmatic API isn't there yet, so Vue, Svelte, Astro and Angular template tooling stay on 6.x until 7.1.

Node stopped needing a build. Type stripping went on by default in Node 23.6, was backported to 22.18, and reached stable in 24.12 in December 2025. It's a 2025 milestone that every LTS line carries in 2026. This runs today on Node 24:

node app.ts

There's one constraint. Stripping erases annotations and never generates code, so enums, namespaces with runtime code, parameter properties and import = are out. TypeScript has a flag that rejects exactly that syntax at check time:

// tsconfig.json
{
  "compilerOptions": {
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "module": "nodenext",
    "target": "esnext"
  }
}

Deno and Bun ran .ts natively already. So the "TypeScript means a compile step" argument is gone on every mainstream runtime. The compiler still exists, but it moved off the run path. It checks in your editor and in CI, and it emits nothing.

What didn't die is the other cost. A dependency with bad or missing types still drags you into any casts, and a clever generic written by someone else is a worse read than the JavaScript it replaced. That cost is real and it isn't going anywhere. It just isn't a build-step argument any more.

One more data point. GitHub's Octoverse 2025 report put TypeScript at number one on the platform by monthly contributors, ahead of Python and JavaScript, and tied the jump to AI-assisted coding. A type checker reads every line an agent writes. No human reviewer does that.

When does TypeScript pay for itself?

TypeScript pays for itself the moment a data shape crosses a boundary: an API response, a message bus, storage, a form, a config file. Inside one function, types are documentation. Across a boundary, they are a contract that a machine enforces.

My clearest example is a Chrome extension, Nudge, an open-source app blocker. A content script talks to a service worker through chrome.runtime.sendMessage, and that API is typed any in both directions. In the first version, a handler that returned the wrong shape produced undefined three screens away, at runtime, on someone else's machine.

The fix was a discriminated union for requests and a map from request type to response type:

export type Request =
  | { type: 'GET_BLOCK_CONTEXT'; target: string }
  | { type: 'COMPLETE_PAUSE'; target: string }
  | { type: 'ADD_SITE'; domain: string; mode: SiteMode; delaySeconds: number }
  | { type: 'GET_SETTINGS' };

export interface ResponseMap {
  GET_BLOCK_CONTEXT: BlockContext;
  COMPLETE_PAUSE: GrantResult;
  ADD_SITE: { ok: boolean; reason?: string };
  GET_SETTINGS: NudgeSettings;
}

export type ResponseFor<T extends Request['type']> = ResponseMap[T];

export async function send<T extends Request>(
  request: T,
): Promise<ResponseFor<T['type']>> {
  return (await chrome.runtime.sendMessage(request)) as ResponseFor<T['type']>;
}

Now send({ type: 'GET_SETTINGS' }) resolves to NudgeSettings and nothing else. Add a request variant without a response entry and the build fails. The mistake moved from a user's runtime to my editor, in twenty lines.

The cast in send is load-bearing and deliberate. sendMessage returns any, so one assertion in one wrapper buys type safety at every call site. That's the trade, made once, in a file I can audit.

The second setting worth its cost is noUncheckedIndexedAccess. It makes arr[i] and map[key] type as T | undefined, which is what they are. This line looks the way it does because the compiler refused the version without the ?? 0:

hourly[hour] = (hourly[hour] ?? 0) + seconds;

In JavaScript the missing hour is undefined, adding to it gives NaN, and the chart renders a gap that nobody reports. Of my three actors, the one with this flag off is not a decision. It's an oversight, and it's now a ticket.

Types stop at the runtime boundary, though. A fetch response typed as Review is still whatever the server sent. I covered that gap in the TypeScript gotcha that silently breaks production. Validate at the boundary, then trust the types inside.

When is plain JavaScript the right call?

Plain JavaScript is the right call when nothing else imports the code. The script that adds anchor links and JSON-LD to my blog posts is 116 lines of Node. One author, one caller, one job. A tsconfig.json would be the second largest file in the directory. It runs, and it's done.

The plain-JS actor is the same shape at a larger size: a scraper with a single output schema, 22 files, JSDoc comments for the next reader, no checker. It has been fine. The honest caveat is that "fine" holds only until a second consumer shows up. The day another actor imports its normaliser, it gets a tsconfig, because at that moment the shape crosses a boundary.

The signal is not line count. It is the number of things that can be wrong about a shape without you noticing.

What about the middle: JSDoc and @ts-check?

There's a third option most comparisons skip. The TypeScript compiler will check a .js file if you ask, with no rename and no build step:

// @ts-check

/**
 * @param {Record<string, number>} hourly
 * @param {number} hour
 * @param {number} seconds
 */
export function addSeconds(hourly, hour, seconds) {
  hourly[hour] = (hourly[hour] ?? 0) + seconds;
}

Same checker, same strict flags through checkJs in tsconfig, and the file stays JavaScript. Svelte's core team moved the compiler's internals to this style in 2023 because the tooling friction of a non-standard language wasn't worth it for library code. The team has debated revisiting that call since, but hasn't reversed it. The public API still ships .d.ts types. It's the right answer for glue code that outgrew "just run it" but has not earned a build. It also suits library authors who want the debugger to show the file they wrote.

The decision rule for 2026

Will anything else import it? No: plain JavaScript. Run it and move on.
Does a data shape cross a boundary? Yes: TypeScript with strict and noUncheckedIndexedAccess, plus runtime validation at the edge.
Neither, but it will outlive the quarter? Then TypeScript anyway, because it will grow a boundary. Otherwise JSDoc with // @ts-check until it does.

The question was never "TypeScript or JavaScript". It was "how much checking does this code earn". In 2026 the checking is free at runtime and cheap at build time, so the only honest reason to skip it is that there's nothing for it to catch.

If you want one thing to do today: open a repo you own and find the first untyped boundary, an API response, a message handler, a config read. Give it a type, validate the input at the edge, and turn on noUncheckedIndexedAccess for that package. That one boundary will tell you whether the rest of the repo has earned it.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

5 Production Failures AI Coding Agents Cause (And the Checks That Catch Them)

Diven Rastdus — Fri, 18 Sep 2026 10:11:44 +0000

AI coding agents rarely ship code that fails the check you gave them. They ship code that passes the check while the thing you cared about is broken. The five failures below all went green through unit tests and CI, then broke on a real device, a real store build, or a real user. The fix was the same every time: move the check from the input the agent controls to the artifact the user runs.

For eight weeks my Play Store build shipped the wrong JavaScript. The manifest was right, CI was green, the env var was set, and the Hermes bundle inside the AAB had the same md5 as the one inside the debug APK. I ship agent-written code to production on two open-source Android apps and a pile of automation scripts. For the last few months I logged every bug that passed review and then broke on a real user. Almost none of them were "the agent wrote wrong code." They were "the agent wrote the code and the test to match, and both agreed with each other while disagreeing with reality." Here are the five patterns, with the incident that taught me each one.

1. The permission that was requested but never declared

An agent will add a runtime permission request and forget the manifest declaration, and Android fails that combination silently. No error, no prompt, just empty data.

The mood tracker I maintain reads heart rate variability from Health Connect. The agent added the HRV record type to the runtime requestPermission() set and shipped. Users reported "there is no HRV view." The view existed. It was starved of data. A health permission that is not declared in the manifest is never offered to the user. It never appears in getGrantedPermissions(), so code that reads only the granted record types quietly skips it. The metric comes back empty with no exception in sight.

That's one fact with two write sites.

The check: an invariant test that locks them together. Swap in your own two constants.

// __tests__/healthPermissionInvariant.test.ts
const runtime = [...REQUIRED_READ_RECORD_TYPES, ...OPTIONAL_READ_RECORD_TYPES]
  .map((t) => RECORD_TYPE_TO_PERMISSION[t])
  .sort();

it('manifest permissions equal the runtime request set, exactly', () => {
  expect([...HEALTH_PERMISSIONS].sort()).toEqual(runtime);
});

Add a record type on one side and the suite fails until the other side matches. Any OS permission that is requested at runtime has this second write site. Lock them.

2. The transaction that wrapped nothing

When a fix depends on a library contract, the agent will honor the shape of the API and ignore the contract, and a mock can't tell the difference.

The same app moved its writes into expo-sqlite's withExclusiveTransactionAsync. The agent ran every statement on the outer db handle instead of the txn argument the callback receives. That API opens a separate connection for the transaction. The txn argument was the transaction. The outer db was not. So a real BEGIN and COMMIT ran on one connection, with nothing inside them, while the writes ran unprotected in autocommit on the other. No lock was ever taken, either. Nothing ran on txn, so the transaction never escalated to a write transaction, and the outer connection sailed through in autocommit.

Jest mocked the transaction helper as "just run the callback," so the tests passed. Device QA passed too, because an unrelated change had hidden the visible symptom. The fix stayed "verified" for two weeks while users kept hitting state bugs.

The check: static. Scan the source and ban the outer handle inside write callbacks. This is the shape of the real test, with a brace-naive regex standing in for the helper.

// writeTransactionInvariant.test.ts
const writeCallbackBodies = (src: string) =>
  [...src.matchAll(/withWrite(?:Transaction|Lock)\(\s*async\s*\(\w+\)\s*=>\s*\{([\s\S]*?)\n\}\)/g)].map((m) => m[1]);

it.each(WRITE_MODULES)('%s never touches the outer db inside a write callback', (file) => {
  const src = stripComments(read(file));
  for (const body of writeCallbackBodies(src)) {
    expect(body).not.toMatch(/\bdb\.(runAsync|execAsync|getAllAsync|getFirstAsync)\(/);
  }
});

When the mechanism of a fix is a callback argument or a handle, read the library source and assert the contract. The symptom disappearing proves nothing.

3. The tests that defended the bug

The suite had 400 green tests, and two of them asserted the exact bug.

The browser extension of my app blocker had a rule engine ported from Android. A hard-block rule with a daily time limit fell through the branch chain to ALLOW. On Android that was a harmless no-op. In the browser the declarativeNetRequest redirect had already fired, so ALLOW became an infinite redirect loop.

The spec had said "a hard block with a limit must not block via the unconditional branch." The agent did what the spec said and wrote two tests to prove it. Only a live browser session with a user-authored config caught it. If the spec describes which branch should run, the agent writes tests that assert the branch, and the suite defends the bug forever.

The check: an invariant over the whole input space, not a regression for the instance.

describe('an applicable rule can NEVER produce ALLOW', () => {
  const MODES = ['HARD_BLOCK', 'DELAY', 'BREATHING'] as const;
  const LIMITS = [null, 60] as const;
  const USAGES = [0, 30 * 60_000, 60 * 60_000 - 1, 60 * 60_000, 90 * 60_000];

  for (const mode of MODES)
    for (const limit of LIMITS)
      for (const ms of USAGES)
        it(`blocks: ${mode} ${limit} ${ms}`, () => {
          expect(evaluate([rule({ mode, dailyLimitMinutes: limit })], ms).type).toBe('BLOCK');
        });
});

That's thirty cases from one sentence of intent. Phrase tests as user-visible outcomes. A test that names an internal branch is a test that will guard whatever that branch does.

4. The suite that collected zero tests

A dead test suite stays invisible for as long as every run is scoped to one file.

One script in my tools directory called sys.exit(2) at import time. Pytest hit it during collection and the whole directory stopped collecting. To be fair to pytest, a bare run is loud about this: it exits 3 when collection blows up and 5 when nothing is collected. Nobody ran it bare. Every agent run for 71 days executed a scoped command like pytest tests/test_one_thing.py, which collected fine and exited 0. The gate was green because the gate was never pointed at the whole suite.

The check: run the whole suite on a schedule, and read the count, not just the exit code.

OUT="$(python3 -m pytest --collect-only -q tests 2>&1)"
COLLECTED="$(printf '%s\n' "$OUT" | grep -oE '^[0-9]+ tests? collected' | grep -oE '^[0-9]+')"
if [ "${COLLECTED:-0}" -lt 50 ]; then
  echo "collection broken: ${COLLECTED:-0} tests (floor 50)" >&2
  exit 1
fi

Any gate needs a floor, and a scoped run is not a gate. The floor is the number you'd be embarrassed to fall under.

5. The build that asserted the input, not the artifact

The agent will verify the env var, the log line, and the manifest, and never open the bundle the user runs.

The mood tracker builds two Android variants from one tree in one CI job. An env knob drives two layers: a config plugin strips the health permissions from the manifest, and Babel inlines the same knob into the JavaScript so the feature card hides. CI asserted the manifest both ways and stopped.

For eight weeks the Play build shipped with the permissions excluded from the manifest and the feature enabled in the JavaScript. Tapping the card called a native module with no permission delegate registered, and the release build died. The cause was three layers down, and it plays out as a timeline:

Metro's transform cache key hashes the transformer files and the config. It doesn't hash env values. (Expo has since added cache-vary handling for some EXPO_PUBLIC_ vars, so check your SDK, but upstream Metro still works this way.)
The cache lives in the OS temp dir, so it survives expo prebuild --clean and both Gradle runs of one job.
The APK step ran first and warmed the cache with the "enabled" output.
The AAB step got cache hits for every file, including the one whose output depended on the env.

One command settled it: the Hermes bundle inside the AAB had the same md5 as the bundle inside the APK.

The check: bake a marker into the code and read it out of each built artifact.

AAB=android/app/build/outputs/bundle/release/app-release.aab
APK=android/app/build/outputs/apk/release/app-release.apk
unzip -p "$AAB" base/assets/index.android.bundle > aab.bundle   # AAB: base/ prefix
unzip -p "$APK" assets/index.android.bundle      > apk.bundle   # APK: no prefix
EN=$(strings aab.bundle | grep -F -c 'hc-variant:enabled' || true)
EX=$(strings aab.bundle | grep -F -c 'hc-variant:excluded' || true)
[ "$EX" -ge 1 ] && [ "$EN" -eq 0 ] || { echo "::error::Play bundle is the wrong variant"; exit 1; }
[ "$(md5sum aab.bundle | awk '{print $1}')" != "$(md5sum apk.bundle | awk '{print $1}')" ] || exit 1

Assert the artifact. An env var, a log line saying the env was set, and a manifest grep are inputs. The thing the user runs is the bundle.

The pattern under all five

An AI coding agent optimizes for the check you hand it, so the check has to point at the thing you would bet the deploy on.

Every one of these bugs lived on the far side of a boundary the checks never crossed. Types, unit tests, and CI exit codes are cheap, and the agent will make all of them green. The manifest on the device, the bundle in the store, the library's real connection handling, and the real user config are expensive, and that's where the bugs waited. The five checks above are each a few lines. What they share is the target. The artifact instead of the input. The outcome instead of the branch. And the whole class of inputs, not the one instance that happened to break on a Tuesday.

If you review agent-written code, add one question to the review. What would have to be true for this test to pass while the feature is broken? If the answer is easy to state, that's the next check to write.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

5 New Python 3.15 Features in 2026 (And 2 I'm Still Waiting For)

Diven Rastdus — Fri, 11 Sep 2026 10:16:03 +0000

lazy import cut one of my CLI tools from 89 ms to 26 ms of startup. One keyword, no other changes.

Python 3.15 ships on October 1, and that's one of five changes that reach the code you write every day. In July I wrote up the 3.14 features that changed how I write code and ended with two things I was still waiting for. So I installed the release candidate with uv python install 3.15.0rc2, ran every example below on it, and kept the numbers.

1. `lazy import` makes slow CLI startup a solved problem

Put lazy in front of a module-level import and Python binds the name immediately but doesn't load the module until the first time you touch it. That's PEP 810. It's the one feature I'd upgrade for on its own.

Here's the shape of half the CLI tools I maintain. Fifteen stdlib imports at the top, and a main() that on most runs touches one of them:

# cli_tool.py
import argparse
import asyncio
import http.client
import ssl
import sqlite3
import xml.etree.ElementTree
import tomllib
import zipfile
# ... 7 more

def main():
    args = argparse.ArgumentParser().parse_args()
    print("ready")

if __name__ == "__main__":
    main()

Prefix every import with lazy and nothing else changes:

lazy import argparse
lazy import asyncio
lazy import sqlite3
# ... same for the rest

Ten runs of each on 3.15.0rc2, median wall time:

script	modules loaded by the time `main()` returns	startup
eager imports	185	89 ms
`lazy` imports	37 (all of them argparse, the one module `main()` uses)	26 ms
bare `python -c pass`	0	13 ms

The eager version spends about 63 ms loading fourteen modules the run never touches. The lazy version still pays for argparse, because main() calls it, and pays for sqlite3 only on the run that calls sqlite3.connect(). You can watch it happen:

import sys
lazy import sqlite3
print("sqlite3" in sys.modules)   # False
sqlite3.connect(":memory:")
print("sqlite3" in sys.modules)   # True

The rules are strict. The errors are good, though. lazy works at module scope only. Inside a function, a class body, or a try block it's a SyntaxError. So are lazy from x import * and lazy from __future__ import. If a lazily imported module doesn't exist, the ImportError surfaces at first use, and the traceback shows both the import line and the line that triggered it.

Two switches matter for real projects. python -X lazy_imports=all (or PYTHON_LAZY_IMPORTS=all) makes every module-level import lazy without touching source, and gave me the same 26 ms. For a library that must still import on 3.14, declare __lazy_modules__ = ["json", "pathlib"] at the top of the module. Older Pythons ignore the name and import eagerly.

One warning: keep imports with side effects eager. Anything that registers a plugin, configures logging, or patches a module on import must not be deferred, or it silently never runs.

2. Unpacking works inside comprehensions

[*sub for sub in lists] flattens a list of lists, and it's the fastest way to do it. PEP 798 allows * and ** inside list, set, and dict comprehensions, which turns the double-for idiom into one line:

lists = [[1, 2], [3, 4], [5]]

[*sub for sub in lists]                  # [1, 2, 3, 4, 5]  (new)
[x for sub in lists for x in sub]        # the 3.14 way

dicts = [{"a": 1}, {"b": 2}, {"a": 3}]
{**d for d in dicts}                     # {'a': 3, 'b': 2}, last write wins

Flattening 1,000 lists of 20 ints with timeit, best of five runs:

idiom	time per flatten
`[x for sub in lists for x in sub]`	201 µs
`list(itertools.chain.from_iterable(lists))`	169 µs
`[*sub for sub in lists]`	73 µs

It's faster because the interpreter extends the result list once per inner list instead of appending one element at a time. On 3.12 and 3.14 the same line is SyntaxError: iterable unpacking cannot be used in comprehension, so this is a 3.15-only idiom, not a backport candidate.

3. `frozendict` is a built-in

frozendict is an immutable, hashable mapping you can use as a dict key, a cache key, or a config object nobody can mutate by accident. It's PEP 814 and needs no import:

>>> cfg = frozendict(host="db", port=5432)
>>> cfg["port"] = 1
TypeError: 'frozendict' object does not support item assignment
>>> pools = {cfg: "pool-1"}
>>> pools[frozendict(port=5432, host="db")]        # order doesn't matter
'pool-1'
>>> cfg | {"port": 6543}
frozendict({'host': 'db', 'port': 6543})
>>> hash(frozendict(a=[1]))                        # values must be hashable too
TypeError: unhashable type: 'list'

The one thing that will bite you: frozendict isn't a subclass of dict. isinstance(cfg, dict) is False. Check against collections.abc.Mapping instead, which also covers MappingProxyType. The stdlib already accepts it where you'd expect, including json.dumps, copy, pickle, and pprint.

4. A profiler that attaches to a live process

python -m profiling.sampling attach <PID> profiles a running Python process from the outside, with no code change, no restart, and no slowdown in the target. The tool is called Tachyon (PEP 799).

It's a separate process that reads the target's memory and rebuilds the stack, so the target pays nothing. Four subcommands, plus a --live flag for a top-style view:

python -m profiling.sampling run hot.py            # run a script under the profiler
python -m profiling.sampling attach 4242           # attach to a live PID
python -m profiling.sampling attach --live 4242    # top-style TUI on a live PID
python -m profiling.sampling dump 4242             # one stack snapshot, no profiling
python -m profiling.sampling replay profile.bin    # convert a saved profile

Two seconds against a script with two hot loops:

Captured 2,001 samples in 2.00 seconds
Sample rate: 1,000.45 samples/sec

  nsamples  sample%  tottime (ms)  cumul%  cumtime (s)  filename:lineno(function)
   943/943     47.1       943.000    47.1        0.943  hot.py:5(hash_loop)
   780/780     39.0       780.000    39.0        0.780  hot.py:11(parse_loop)

Add --flamegraph for a self-contained HTML flame graph, --gecko for the Firefox Profiler, --mode gil to see who holds the GIL, or --async-aware for asyncio code. The docs quote rates up to 1,000,000 samples per second; the default 1,000 nailed the split above.

One Linux gotcha: attach reads another process's memory, so a stock Ubuntu (kernel.yama.ptrace_scope=1) refuses it even for your own processes. The error message tells you the fixes: sudo -E, echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope, or --cap-add=SYS_PTRACE in Docker. run mode needs none of that. The old deterministic profiler now lives at profiling.tracing, and cProfile still imports.

5. `sentinel` kills the `object()` trick

MISSING = sentinel("MISSING") gives you a unique "no argument was passed" marker with a readable repr, and it's a built-in (PEP 661). Every codebase I've touched reinvents this with a bare object():

>>> import pickle
>>> MISSING = sentinel("MISSING")
>>> def fetch(key, default=MISSING):
...     if default is MISSING:
...         raise KeyError(key)
...     return default
>>> MISSING
MISSING
>>> int | MISSING                                  # valid in a type annotation
int | MISSING
>>> pickle.loads(pickle.dumps(MISSING)) is MISSING
True

Identity survives pickling and copying, which the object() trick never did, and the repr says MISSING instead of <object object at 0x7f...>.

The smaller wins I already use

open("notes.txt") is UTF-8 on every platform now (PEP 686), so the "written on Linux, read on Windows as cp1252" bug is gone. PYTHONUTF8=0 if a legacy pipeline needs the old behaviour.
asyncio.TaskGroup.cancel() ends a group early without try/except boilerplate. I use it for "take the first result, drop the rest".
os.makedirs(path, parent_mode=0o755) and Path.mkdir(parent_mode=...) set a separate mode for the intermediate directories.
json.loads(text, array_hook=tuple) turns JSON arrays into whatever you want, the way object_hook always did for objects.
Error messages now speak other languages: [1, 2].push(3) says Did you mean '.append'?, and (1, 2).append(3) asks whether you wanted a list.
argparse --help, timeit, ast, sqlite3, and http.server output got colour, and difflib.unified_diff() grew a color=True parameter for git-style diffs.

What I'm still waiting for

Both wishes from the 3.14 post are closer, and neither has arrived.

The JIT on by default. The 3.15 JIT is a real upgrade. The What's New page reports pyperformance results of roughly 8 to 9 percent geometric-mean speedup on x86-64 Linux over the standard interpreter. On AArch64 macOS it's 12 to 13 percent over the already faster tail-calling interpreter. The page flags both numbers as not final. It still ships off. The official Windows and macOS binaries build it in, but you opt in with PYTHON_JIT=1. PEP 836, still a draft, proposes the bar the JIT would have to clear to stop being experimental. I want the release where I forget the environment variable exists.

Free-threading as the plain python. The no-GIL build is still a separate build in 3.15. What landed is the plumbing: PEP 803 defines a stable ABI for free-threaded builds (abi3t), so extension authors can ship one wheel that works there. The What's New page also notes that setuptools, meson-python, scikit-build-core, and Maturin don't support abi3t yet. When they do, the wheel ecosystem can catch up, and then the default build can change. Not this year.

What to do this week

Install the release candidate (uv python install 3.15.0rc2) and run your test suite against it. When it passes, make three changes in this order. Add lazy to the heavy imports in every CLI entry point and measure the startup. Replace your flatten idioms with [*sub for sub in lists]. Switch your immutable config objects to frozendict. Then, the next time a process is slow in production, attach Tachyon to it before you touch the code.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

How MCP Actually Works: The Protocol Behind Every AI Agent Integration

Diven Rastdus — Wed, 09 Sep 2026 10:15:07 +0000

MCP isn't a framework, an SDK, or an AI feature. It's JSON-RPC 2.0 sent over stdio or HTTP, where every request carries its own protocol version and capabilities. That's the entire protocol, and you can hold all of it in your head at once.

I run several MCP servers in production and I've written both sides of the wire. The protocol took an afternoon to learn. The failures took considerably longer, and none of them are in the quickstart. So this is the protocol on one page, followed by the five things that broke for me after it was supposedly working.

What MCP actually is

MCP is a client-host-server protocol where one host runs many clients, and each client talks to exactly one server. The architecture page is blunt about the ratio: "each client having a 1:1 relationship with a particular server." Your host app (Claude Code, Cursor, your own agent loop) holds the model. Connect five servers and you've got five clients inside one host.

That rule explains API design that otherwise looks like an omission. There's no routing layer, no server registry, no addressing scheme on the wire. A message on a connection is unambiguously for that server, so nothing needs to say which server it means.

One more principle worth knowing: servers can't read the whole conversation or see into each other. Isolation between servers is the host's job, not the protocol's.

What changed in the current revision

The current revision, 2026-07-28, deleted the initialize handshake and made MCP stateless. The architecture page states it directly: "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities." This was well covered when it landed, so treat it as context rather than news. It also silently invalidates a lot of older tutorials.

There's no session to open. Every request carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in its _meta field, and the server accepts or rejects that request on its own. Send an unsupported version and you get back error -32022 listing the versions the server does support, so you retry with one of those. If you'd rather ask up front, servers MUST implement server/discover; calling it is optional.

The spec calls the old world "legacy" (2025-11-25 and earlier) and the new one "modern". Mixed eras fail unless one side implements both, so if you're staring at a dead connection, check that first.

The second breaking change got much less attention: servers can no longer initiate JSON-RPC requests at all. The spec is flat about it, "servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses." Anything a server used to ask the client for, sampling, elicitation, roots, now comes back inside a reply as an InputRequiredResult with resultType: "input_required". The client answers by retrying the original call with inputResponses and the server's opaque requestState, using a different JSON-RPC id. If you wrote a server that calls back into the model, it's broken, and it probably fails quietly.

Two transports, and only two

The spec defines exactly two standard transports. stdio launches the server as a subprocess and exchanges newline-delimited JSON-RPC over its standard streams. Streamable HTTP POSTs each message to a single endpoint, and replies arrive either as a JSON object or a request-scoped SSE stream.

The older two-endpoint HTTP+SSE transport has been deprecated since 2025-03-26. If a tutorial has you opening a long-lived GET for events, that tutorial is old.

Which transport you get comes down to which key you wrote. This shape is host-tooling convention, not protocol spec:

{
  "mcpServers": {
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data"] },
    "analytics":  { "type": "http", "url": "https://mcp.example.com/mcp" }
  }
}

A command key means a subprocess on your machine. A url key means an HTTP request to someone else's. That difference matters more than it looks, because only one of them can read your environment variables.

What a tool definition actually is

A tool is a name, a description, and a JSON Schema for its arguments, plus optional extras like title, outputSchema, icons, and annotations. In Python it's a decorator, and the docstring becomes the description:

@mcp.tool()
def conversations_list(platform: Optional[str] = None, limit: int = 50) -> str:
    """List active messaging conversations across connected platforms.

    Args:
        platform: Filter by platform name (telegram, discord, slack, etc.)
        limit: Maximum number of conversations to return (default 50)
    """

Here's what took me too long to internalize: that description is prompt text. It isn't documentation for a human reading your repo. It's serialized into the model's context and it's the only basis the model has for picking your tool over another. A vague description is a tool the model never calls. A description carrying Example: "amoxicillin, ibuprofen" is a tool it calls correctly the first time.

The round trip of one tool call

The model picks a tool, the client sends tools/call, the server runs your code, and the result goes back into context. Two details in that last step surprise people.

A tool result carries both content and structuredContent. The first is what the model reads. The second is server-produced JSON for your code, validated against outputSchema if you defined one. The spec says a tool returning structured content SHOULD also serialize it into a text block. For a human-facing agent I usually don't, because paying context tokens for JSON syntax the model doesn't need adds up.

Errors come in two flavours that behave nothing alike. A malformed request or unknown tool is a protocol error, a normal JSON-RPC error. A failure inside your tool is a tool execution error, returned as a successful result with isError: true. The spec is explicit that clients SHOULD hand those to the model so it can self-correct, which means your error strings are prompt text too. "Invalid input" teaches the model nothing. "drug_names must be comma-separated, you sent an array" gets a correct retry.

The parts that only break in production

Five things broke for me after MCP was supposedly working: colliding tool names, schemas that aren't portable across model providers, a 2xx from something that isn't an MCP server, cached tokens that lie about their own expiry, and state that no longer survives between calls. Everything above works on the first try in a demo. These cost me real days.

Tool names aren't namespaced. Uniqueness is scoped to a single server, so two servers can both export search. The spec tells aggregating clients to "implement a disambiguation strategy such as prefixing tool names with a server identifier", and warns the server's own name isn't guaranteed unique either. Mine registers everything as mcp_{server}_{tool}.

JSON Schema isn't portable across model providers. One schema from one server doesn't just work everywhere. Some providers reject #/definitions/... and need #/$defs/.... Some return a 400 when required names a property missing from properties. Some reject nullable anyOf unions in tool inputs. My client runs a normalization pass over every incoming schema, and that pass exists entirely because of provider-specific rejections.

A 2xx doesn't mean you reached an MCP server. Point a url at a normal web app and it answers HTML with a 200. The SDK then waits out the whole connect timeout before surfacing an opaque cancellation. A content-type preflight turns a 60 second mystery into a one second error, so check for application/json or text/event-stream first.

Cached tokens lie after a restart. Load a token from disk and its expiry can come back unset, which reads as valid no matter how old it is. You ship a stale token, and the failure isn't always a clean 401. One provider of mine returned 200 with an application-level auth error in the body, invisible to the transport layer and indistinguishable from an empty result set.

Statelessness is now your problem. Since there's no session, a server can't relate one call to the next. Anything spanning calls, a cart, a browser context, a transaction, needs an explicit handle returned by one tool and passed as an argument to the next. The spec's design guidance is non-normative here but worth obeying: "a handle is a name, not a capability." Validate authorization against it on every call, or anyone who guesses a handle inherits that state.

Tool descriptions are attack surface

A server you didn't write controls text that lands in your model's context, and the model is expected to act on it. The spec's warning is unambiguous: clients MUST consider tool annotations untrusted unless they come from trusted servers.

My client scans incoming descriptions for the obvious shapes:

_MCP_INJECTION_PATTERNS = [
    r"ignore\s+(all\s+)?previous\s+instructions",
    r"you\s+are\s+now\s+a",
    r"<\s*system\s*>",
    r"do\s+not\s+(tell|reveal)",
]
# WARNING-level only: we log but do not block, since false
# positives would break legitimate MCP servers.

That comment is the honest state of the art. We log, we don't block, because blocking on a regex breaks real servers. Detection isn't a solution here.

What works is narrowing reach. A stdio server is a subprocess that inherits your environment by default, so every API key you hold is one os.environ away from someone else's code. I pass an explicit allowlist instead (PATH, HOME, USER, LANG, the XDG_* vars) and nothing more. I also strip credential-shaped patterns out of error text, since an error string is an easy way to leak a token into a transcript you later paste in public.

The takeaway

MCP is small: JSON-RPC, per-request metadata, and a list of tools whose descriptions are prompts. Most of what goes wrong comes from treating it as bigger and more magical than that.

Write tool descriptions as if the model is your only reader, because it is. Namespace your tool names yourself, since nothing else will. And treat every description from a server you didn't write as untrusted text that's about to enter your model's context, because that's exactly what it is.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

Building a Real-Time Dashboard with Python and FastAPI (No WebSockets)

Diven Rastdus — Mon, 07 Sep 2026 10:19:51 +0000

A real-time dashboard in Python doesn't need WebSockets. Dashboard data flows one way, from server to browser, and Server-Sent Events do exactly that over ordinary HTTP. One endpoint, no protocol upgrade, no extra dependency, and the browser handles reconnection itself. FastAPI already ships everything required.

Most metrics start life as a file. You have counters in a database, or a JSONL file some job appends to, and to see what changed you re-run a script and read the tail. That works until you want to watch it. Then you start refreshing, and refreshing is just polling done by a human.

Here's the shape of the whole thing. One producer, many browsers, and one bounded queue per browser.

The complete runnable code, including the test suite, is in this gist.

Why not WebSockets?

A dashboard never talks back, so a WebSocket buys you a bidirectional channel you never use. You pay for it with a protocol upgrade, a separate deployment story, and reconnection logic you write yourself. SSE is plain HTTP. It passes through proxies, it works with the auth middleware you already have, and reconnection is a browser feature rather than your code.

Reach for WebSockets when the client genuinely sends messages: chat, collaborative editing, multiplayer. For numbers on a screen, SSE is less machinery for the same result.

Fan out with one bounded queue per client

Give every connected browser its own bounded asyncio.Queue and drop the oldest message when it fills, so one slow client can never stall the producer. The load-bearing word is bounded.

import asyncio, json, random
from contextlib import asynccontextmanager, suppress
from typing import AsyncIterator

from fastapi import FastAPI, Request
from fastapi.responses import HTMLResponse, StreamingResponse


class Broker:
    """Pub/sub fan-out. Every subscriber owns a BOUNDED queue, so a slow
    browser tab can never apply backpressure to the producer."""

    def __init__(self, maxsize: int = 10) -> None:
        self._maxsize = maxsize
        self._subscribers: set[asyncio.Queue[str]] = set()
        self.dropped = 0

    @property
    def subscriber_count(self) -> int:
        return len(self._subscribers)

    def publish(self, message: str) -> None:
        """Never awaits. If a subscriber is full, evict its oldest message
        (stale metrics are worthless) and count the drop."""
        for queue in self._subscribers:
            try:
                queue.put_nowait(message)
            except asyncio.QueueFull:
                queue.get_nowait()
                queue.put_nowait(message)
                self.dropped += 1

    @asynccontextmanager
    async def subscribe(self) -> AsyncIterator[asyncio.Queue[str]]:
        queue: asyncio.Queue[str] = asyncio.Queue(maxsize=self._maxsize)
        self._subscribers.add(queue)
        try:
            yield queue
        finally:
            self._subscribers.discard(queue)  # a disconnect always cleans up


broker = Broker()

publish() never awaits, and that's the whole design. If you await a slow client, one laptop on hotel wifi backs up the producer and stalls every other viewer. Bounding the queue and dropping the oldest entry turns that outage into a counter. For metrics, that trade is obviously right, because nobody wants a stale number delivered late.

Staying synchronous buys a second property for free. Because publish() never yields control, no client can disconnect mid-broadcast and mutate the set underneath the loop.

subscribe() is an async context manager, so a dropped connection always removes its queue. That matters more than it sounds. A leak here stays invisible until you've run for a week and every disconnected tab is still holding memory.

Start the producer with lifespan, not on_event

Start background producers in FastAPI's lifespan context manager rather than @app.on_event("startup"). If you pass lifespan, the old startup and shutdown handlers never run at all. FastAPI's own docs are blunt here. "If you provide a lifespan parameter," they warn, "startup and shutdown event handlers will no longer be called."

async def metrics_producer(target: Broker) -> None:
    tick = 0
    while True:
        tick += 1
        target.publish(json.dumps({
            "tick": tick,
            "rps": round(random.uniform(80, 240), 1),
            "latency_ms": round(random.uniform(12, 90), 1),
            "clients": target.subscriber_count,
        }))
        await asyncio.sleep(1.0)


@asynccontextmanager
async def lifespan(app: FastAPI) -> AsyncIterator[None]:
    task = asyncio.create_task(metrics_producer(broker))
    try:
        yield
    finally:
        task.cancel()
        with suppress(asyncio.CancelledError):
            await task


app = FastAPI(lifespan=lifespan)

Swap the random numbers for your real stats source. The cancel-and-suppress in the finally block is what makes shutdown quiet instead of dumping a cancellation traceback.

The endpoint, and what a frame actually looks like

An SSE frame is just text with a blank line at the end.

async def event_stream(request: Request) -> AsyncIterator[str]:
    async with broker.subscribe() as queue:
        event_id = 0
        while True:
            try:
                payload = await asyncio.wait_for(queue.get(), 15.0)
            except TimeoutError:
                yield ": ping\n\n"  # comment frame: keeps idle proxies from reaping us
                continue
            if await request.is_disconnected():
                break  # drops this one message; fine for metrics, not for orders
            event_id += 1
            yield f"id: {event_id}\nevent: metrics\ndata: {payload}\n\n"


@app.get("/events")
async def events(request: Request) -> StreamingResponse:
    return StreamingResponse(
        event_stream(request),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no",  # nginx would otherwise buffer the stream
        },
    )

Three details carry the weight. A blank line terminates a frame. A line starting with : is a comment, which is why the heartbeat is spelled : ping. And data: has to be a single line, which json.dumps() guarantees for free.

The timeout doubles as the heartbeat. A plain await queue.get() gives you nowhere to emit a keepalive on an idle stream, so an idle connection sits silent until some proxy decides it's dead. Wrapping the get in wait_for lets one loop handle both data and liveness.

Here's what curl sees, at roughly one frame per second:

id: 1
event: metrics
data: {"tick": 18, "rps": 121.9, "latency_ms": 40.3, "clients": 1}

id: 2
event: metrics
data: {"tick": 19, "rps": 205.5, "latency_ms": 62.6, "clients": 1}

The browser needs nine lines

The browser side is nine lines: new EventSource("/events"), one event listener, and no reconnect logic at all.

// EventSource reconnects on its own and sends the last `id:` back as a
// Last-Event-ID header, so the server *can* resume you, if it keeps a replay
// buffer. This one doesn't. It just picks up live.
const es = new EventSource("/events");
es.addEventListener("metrics", (e) => {
  document.getElementById("state").textContent = "live";
  for (const [k, v] of Object.entries(JSON.parse(e.data))) {
    const el = document.getElementById(k);
    if (el) el.textContent = v;
  }
});
es.onerror = () => { document.getElementById("state").textContent = "reconnecting..."; };

No reconnect loop, no exponential backoff, no library. Kill the server and the numbers freeze while the label flips to reconnecting.... Start it again and they resume.

The four things that silently break (hanging tests, dead producers, nginx, and the six-connection cap)

Each of these looks like a bug in your own code. None of them are.

Your tests hang forever. httpx.ASGITransport buffers the entire response body before returning, so client.stream("GET", "/events") against an endless stream never returns at all. Even response.status_code is unreachable. It looks exactly like a deadlock in your own broker. Drive the ASGI app directly and cancel after N frames, or run a real server in a fixture.

Your producer never starts under test. ASGITransport doesn't run lifespan, so nothing publishes and every test reads zero frames. TestClient does run it, but only as a context manager. A bare TestClient(app) without with skips lifespan too, and just as silently. If you export your lifespan function you can enter it in a fixture with async with lifespan(app): and skip the extra dependency. Migrating from on_event to lifespan changes test behaviour without a warning, which is the real trap.

nginx buffers your stream. Every local curl looks perfect without X-Accel-Buffering: no, and then production delivers your "real-time" events in batches every few KB. This one stays invisible until you deploy behind a proxy.

You get six connections per domain. Over HTTP/1.1 most browsers cap simultaneous connections to one domain at six, and that budget is shared across tabs. A few open dashboards can starve the rest of your app. Over HTTP/2 the negotiated stream limit defaults to around 100, so serving the thing over HTTP/2 makes the problem disappear.

Bound the queue, drop the oldest

The streaming is never the hard part. Roughly 120 lines gets you a live dashboard, and most of it is ordinary FastAPI. The hard part is deciding what happens when one client can't keep up. Bound the queue, drop the oldest frame, count the drops. A number that arrives late is worse than a number that never arrives, because you'll trust it.

Clone the gist, run uvicorn app:app, and open two tabs to watch the client counter move. Then shorten the heartbeat interval and watch the bytes, rather than reading the code and assuming.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me there or at theagentthatcould@gmail.com.

How to Give Your AI Agent a Context Budget That Actually Works

Diven Rastdus — Fri, 04 Sep 2026 10:15:32 +0000

Your agent isn't running out of context. It's drowning in it, because the share of the window that still matters keeps shrinking while the window itself keeps growing.

I've been running an agent continuously for months, and it fails in a very specific way. Give it a fresh session and one task, and it's sharp. Let the same session run for forty turns, and the quality falls off a cliff on work it handled fine an hour earlier. Nothing crashed. No limit was hit. It just got worse.

(Shape is illustrative. The ratio is the point, not the exact percentages.)

The fix is to stop treating the window as one container and start treating it as a budget with three tiers. A small hot layer you re-send every turn. A warm layer scoped to the task in front of you. A cold layer that sits on disk and costs nothing until you query it.

Why does an AI agent get worse the longer it runs?

Because a conversation is append-only by default, and every token you added on turn 3 is still being re-sent on turn 40.

The model doesn't forget the early context. It drowns in it. On turn 3, those three files you read were the entire point of the turn. By turn 40 you're on a different problem, and those files are still sitting there, competing for attention with the thing you actually need right now. Nothing removed them, because nothing was ever made responsible for removing them.

That costs you twice. Quality drops, because attention is finite and you spent it on stale tool output. Cost climbs, because every turn re-sends the whole history. A conversation sitting at 200K tokens that runs 40 more turns bills those 200K tokens 40 more times. (Caching softens that bill. It doesn't fix the underlying problem, and I'll come back to why.)

Notice what isn't happening in that chart. Neither window filled up. Both had room to spare. Fullness was never the problem.

What is a context budget?

A context budget splits everything the agent could know into three tiers, ranked by how often each one gets re-sent.

The tiers aren't about importance. They're about frequency. Your decision log might be the most valuable text you own, and it still belongs in cold storage, because you need two lines of it once a week. The system prompt might be dull boilerplate, and it belongs in hot, because it shapes every single turn.

One rule per tier follows from that split.

Rule 1: Cap the hot layer, and let a script enforce it

Anything loaded on every turn needs a hard token ceiling checked by code, because going over budget usually truncates quietly instead of raising an error.

Measure it with the real tokenizer:

from anthropic import Anthropic

client = Anthropic()
HOT_BUDGET = 4000  # tokens re-sent on every single turn

def count(text: str) -> int:
    return client.messages.count_tokens(
        model="claude-opus-5",
        messages=[{"role": "user", "content": text}],
    ).input_tokens

used = count(open("AGENT.md").read())
print(f"hot layer: {used}/{HOT_BUDGET} tokens")
if used > HOT_BUDGET:
    raise SystemExit(f"over budget by {used - HOT_BUDGET} tokens")

Run that in CI. The endpoint is free and sits on its own rate limit pool, so the check costs you nothing. A hot layer with no enforced ceiling grows every week, because adding one more rule always feels free in the moment.

Don't reach for tiktoken here. It's OpenAI's tokenizer, not Claude's, and there's no offline Claude tokenizer to swap in. It undercounts, and it undercounts worse on code than on prose. The count isn't even stable across Claude models. Anthropic's own migration guidance says the tokenizer introduced with Claude 4.7 can produce up to roughly a third more tokens on identical text. A budget you measured six months ago is a budget that's wrong today. Count against the model ID you actually ship.

Silent truncation is the part that bites. My own always-loaded startup context runs under a hard character cap, and the harness that injects it drops anything past that cap without complaining. Go over, and you lose the tail. Nothing tells you. The rule that came out of that: adding to the hot layer is a spending decision. A new line earns its place only if it prevents more trouble than it costs.

Rule 2: Retrieve instead of re-reading

Never load a whole file into context to recover one fact. Index it once, then query for the handful of lines that answer the question.

SQLite bundles a full-text search engine, FTS5, compiled in by default on virtually every standard Python build. No new infrastructure:

import sqlite3, pathlib

db = sqlite3.connect("notes.db")
db.execute("CREATE VIRTUAL TABLE IF NOT EXISTS notes USING fts5(path, body)")
db.execute("DELETE FROM notes")  # rebuild, so a second run doesn't duplicate every row

for p in pathlib.Path("docs").rglob("*.md"):
    db.execute("INSERT INTO notes VALUES (?, ?)", (str(p), p.read_text(errors="ignore")))
db.commit()

rows = db.execute(
    "SELECT path, snippet(notes, 1, '>>', '<<', ' ... ', 20) "
    "FROM notes WHERE notes MATCH ? ORDER BY rank LIMIT 5",
    ("retry AND webhook",),
).fetchall()

for path, snippet in rows:
    print(path, snippet)

That's standard library only. No vector database, no embedding bill, no service to keep alive. An FTS5 index over a few thousand markdown files answers in tens of milliseconds, fast enough to query mid-turn instead of guessing.

Five snippets instead of five files. Reach for embeddings when you genuinely need semantic recall, but keyword search already answers most questions shaped like "what did I decide about X".

Rule 3: Make the warm layer someone else's problem

When a task reads a lot but answers little, run it in a subagent. The reading lands in that agent's window, and only the conclusion lands in yours.

The asymmetry is the whole trick. Reading forty files to answer one architectural question can run into six figures of tokens. The answer is 200 words. If your main loop does that reading, it carries every one of those tokens for the rest of the session. If a subagent does it, the main loop pays for 200 words.

The dispatch needs an explicit return contract:

CONTRACT = """
Search the repo and answer the question below.

Return at most 200 words: the answer, the file:line references that support it,
and nothing else. Do not paste file contents back into your reply.
If the repo does not answer it, reply exactly: blocked: <what you need>.
"""

That last line matters more than it looks. A vague subagent prompt comes back as a confident guess, and a confident wrong answer costs far more than the tokens you saved, because everything downstream gets built on it. Give the subagent the access to look things up itself, and give it explicit permission to come back empty.

Can the API clear old context for me?

Yes. Context editing strips stale tool results out of the history in place. It's the server-side cousin of the subagent trick:

client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    betas=["context-management-2025-06-27"],
    context_management={"edits": [{"type": "clear_tool_uses_20250919"}]},
    tools=[...],
    messages=[...],
)

That clears old tool output rather than summarizing it, which is what you want when most of your history is tool results nobody will read again. There's a clear_thinking_20251015 strategy too. The bare form above runs on defaults, so set an explicit trigger threshold once you know what your loop actually looks like.

Rule 4: Keep durable state on disk, not in the conversation

Anything that has to outlive the session belongs in a file, because the conversation is the one storage layer guaranteed to disappear.

Here's the test I use. If this session died mid-task right now, could a fresh one pick the work up from what's on disk? If the answer is no, your state is sitting in the wrong tier.

state/
  ACTIVE.md      # what I am doing now, and the next concrete step
  DECISIONS.md   # what I chose, and why (the why is the expensive part)
  LESSONS.md     # what broke, and the rule that stops a repeat
  notes.db       # the FTS5 index over all of it

Only ACTIVE.md is hot. Everything else is cold and gets queried. Write the reasoning, not just the outcome, because the outcome is usually recoverable from the code and the reasoning never is. That's also where the compounding shows up: a lesson written down once becomes a rule that costs almost nothing to carry forever.

Does prompt caching solve this instead?

Caching makes re-sending a long prefix much cheaper, but it does nothing about relevance, so it fixes your bill and not your quality.

It's still worth setting up properly. Caching is prefix matched, so any byte that changes invalidates everything after it. Keep stable content first (a frozen system prompt, a deterministically ordered tool list) and put volatile content (timestamps, request IDs, the varying question) after your last breakpoint. Then check usage.cache_read_input_tokens on real traffic. If it reads zero across repeated requests, a datetime.now() in the system prompt is the usual culprit. The other one is subtler: the minimum cacheable prefix depends on the model, so a prompt that's simply too short silently never caches at all.

Real money, genuinely. But a cached irrelevant token is still an irrelevant token sitting in the window. Budget first, then cache what survives.

The takeaway

Pick the rule your agent breaks worst and fix only that one this week. For most people it's the first one, because almost nobody has measured the layer they re-send a thousand times a day.

Measure it once. You'll either find nothing, or you'll find the reason your agent goes stupid after lunch.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

How I replaced react-native-chart-kit with 1,355 lines of react-native-svg

Diven Rastdus — Fri, 04 Sep 2026 05:58:52 +0000

Four separate complaints about my mood tracker's chart had one root cause: the charting library owned the geometry, and the geometry was the thing users were complaining about. So I deleted the dependency and drew the chart myself with react-native-svg. The replacement is 1,355 lines of TypeScript across five files, 750 of them pure functions with no React imports at all.

SoulSync is an open-source mood tracker on Android. Its Statistics tab started life on react-native-chart-kit, the default answer to "how do I draw a line chart in React Native". It's a fine default right up until you want the chart to do something.

What was actually wrong with the library chart

Four defects: one flat stroke whatever the value, a bezier that overshot the data, a slot-indexed x axis, and no way to scrub it. Only the first is cosmetic.

One flat stroke, whatever the value. A mood of 3 and a mood of 8 were painted in the same colour at the same weight. Users kept saying the line was "not bright enough", which turned out to mean "I can't tell the good days from the bad ones".

The bezier overshot the data. A smooth curve between a 4 and a 9 dips below 4 on the way in. On a 0 to 10 mood scale that's a mood the user never had.

The x axis was slot-indexed, not a time axis. My query only returns days that were logged. Plot those consecutively and a three-month silence sits the same distance from its neighbour as a one-day silence. Worse, the "14-day moving average" I was labelling was really a 14-entry average. It was quietly wrong on exactly the sparse data where a trend line matters most.

No way in. Users wanted to hold the chart and drag along it, reading each day as they went. 6.x does give you onDataPointClick and a decorator prop for painting extra SVG on top, which covers tapping a dot. What it doesn't hand you is the touch stream or the x-to-index mapping, so a continuous scrub with nearest-point hit-testing isn't something you can build on top of it. The library also sized itself from Dimensions.get('window') instead of measuring its own container, so it never quite fit its card.

The part where I was wrong about the library

I removed chart-kit believing it was unmaintained. That belief was two months stale, and I should say so plainly.

Here's the real release history from npm. Version 6.12.0 shipped in February 2022 and then nothing moved for four years, which is where my impression of the project froze. It woke up in 2026: 6.12.1 in April, 6.12.3 in May, a next train through May and June, and v7.0.0 on 27 June 2026. It's on 7.0.2 now with 133k weekly downloads.

It gets worse for me. My lockfile had carried the app to 6.12.3, a May 2026 release, so I wasn't even running the four-year-old code I thought I was. What I was running was the pre-v7 architecture. The 6.12.x releases are maintenance work on the original LineChart, and the rewrite lives behind v7's /v2 subpath, which 6.12.3 doesn't ship at all.

v7 is a substantial rewrite behind a react-native-chart-kit/v2 subpath. Its release notes list "multi-series data, null gaps, smart labels, tooltips, crosshair, scrollable viewports, pan/zoom controls, range selector, markers, reference overlays, thresholds, decimation, and accessibility helpers", plus renderer-agnostic core packages for scales, layout, geometry and interaction. Read that against my list above. Null gaps and a crosshair address defects three and four directly. If I'd checked npm instead of my memory of npm, "upgrade" was a real option I never priced.

I'd still make the same call, and the reasons that survive are better than the one I used:

The colour ramp is shared app state, not chart config. The line is painted from the same mood ramp as the timeline dots and the heatmap cells. A theming API gives me a second palette that drifts from the first one on the next redesign.
Half the geometry already existed. The Home tab's week chart left chart-kit three months earlier, and its pure chartGeometry.ts was sitting right there. The marginal cost of the second chart was 750 lines, not 1,355.
A library that owns pan and zoom is a third competitor for the same finger. More on that below. It's the reason I'd have had to fight v7's interaction layer rather than use it.

That's a narrower claim than "the library is dead", and it's the one I can defend.

The other obvious move was a different library. victory-native does 508k weekly downloads and react-native-gifted-charts does 248k, and both handle gestures properly. Same three reasons apply to both, plus one more: swapping libraries is the same migration cost as writing it, without the part where I get to keep the geometry.

Split the geometry out before you draw anything

No coordinate math lives in the component. Every domain, gridline, gradient stop and hit-test is a pure function in a transforms/ folder with zero React or React Native imports. The renderer is thin enough to be boring.

That's not architecture for its own sake. A chart's bugs are almost all arithmetic, and arithmetic is the part you can test without a screen. Here's the vertical domain resolver, which answers "what range does this axis cover":

export const resolveDomain = (
    values: readonly (number | null | undefined)[],
    mode: DomainMode
): ValueDomain => {
    if (mode === 'fixed') return MOOD_DOMAIN;   // always 0..10

    let min = Infinity, max = -Infinity;
    for (const v of values) {
        if (typeof v !== 'number' || !Number.isFinite(v)) continue;
        if (v < min) min = v;
        if (v > max) max = v;
    }
    if (min === Infinity) return MOOD_DOMAIN;   // empty DB is a real code path

    const pad = Math.max(FIT_PAD_MIN, (max - min) * FIT_PAD_RATIO);
    let lo = clamp(Math.floor(min - pad), MOOD_MIN, MOOD_MAX);
    let hi = clamp(Math.ceil(max + pad), MOOD_MIN, MOOD_MAX);

    // Widen to a minimum span. A two-point series spanning 0.2 of a mood
    // would otherwise render as a dramatic mountain range.
    while (hi - lo < FIT_MIN_SPAN) {
        if (hi < MOOD_MAX) hi += 1;
        else if (lo > MOOD_MIN) lo -= 1;
        else break;
    }
    return { min: lo, max: hi };
};

Two modes, because they answer different questions. fixed is always 0 to 10, so this week and last week stay comparable at a glance. fit zooms to the data's own range, which is what you want when every day was a 6 or a 7. FIT_MIN_SPAN is 3, because a fitted domain of 6.1 to 6.3 turns statistical noise into a mountain range.

The bounds snap to integers, so axis labels are whole moods and never "6.37".

Colour that carries information

The line is painted with a vertical gradient built from the app's single mood ramp, so height reads as colour and not just position. High is green, low is amber and red. There's deliberately no second palette.

The interesting part is a constant:

/**
 * The canonical mood ramp bottoms out at 0.2 alpha. A fill can live there;
 * a 3px stroke cannot, and that faintness IS the "not bright enough"
 * complaint. The ramp's shape is preserved, its floor is raised.
 *
 * 0.85 (was 0.55): at 0.55 the stroke visibly DIMMED as it descended, so a
 * bad week looked like a rendering fault rather than a low mood.
 */
const LINE_MIN_OPACITY = 0.85;

I shipped 0.55 first and it was wrong. A ramp tuned for filled shapes doesn't transfer to a 3px stroke, because a stroke has almost no area to carry the alpha. The fix keeps the ramp's shape and rescales it into a legible opacity window, instead of inventing a second ramp that would drift from the rest of the app.

Hold to scrub, tap to expand

A long-press-then-drag Pan from react-native-gesture-handler gives you the whole scrub interaction in six lines, and a ref keeps it from re-rendering the chart on every pointer sample.

const scrub = Gesture.Pan()
    .activateAfterLongPress(SCRUB_ACTIVATE_MS)   // 220
    .runOnJS(true)
    .onStart((e) => handleScrub(e.x))
    .onUpdate((e) => handleScrub(e.x))
    .onFinalize(endScrub);

// Race, not Simultaneous: a quick tap expands, a hold scrubs, never both.
return onPress ? Gesture.Race(scrub, tap) : scrub;

runOnJS(true) is deliberate, not laziness. The readout is React state and the haptic is a JS call, so there's nothing here worth a worklet.

The ref is what stops a re-render storm. Gesture callbacks write the current index to scrubIndexRef and only call setState when the index actually changes. On a slow drag across a month that's about 30 updates instead of thousands.

Hit-testing is a separate pure function, and its comments are mostly about edges:

export const nearestIndex = (x: number, xs: readonly number[]): number | null => {
    if (xs.length === 0) return null;
    let best = 0, bestDist = Math.abs(xs[0] - x);
    for (let i = 1; i < xs.length; i++) {
        const d = Math.abs(xs[i] - x);
        // Strictly-less keeps the EARLIER point on an exact tie, so a scrub
        // across a midpoint switches once, at the midpoint, in both directions.
        if (d < bestDist) { best = i; bestDist = d; }
    }
    return best;
};

xs holds only the real data points, so a hold can never report a mood for a day that was never logged. Dragging past either end clamps to that end rather than dropping the cursor, because a cursor that vanishes mid-drag reads as a bug.

One product decision is buried in there. The tooltip shows the day's average and the last entry the user actually wrote that day, with its time and the first line of its note. An average isn't what anyone remembers about a Tuesday. The entry is.

Two Pan gestures, one finger

Two Pan handlers and a vertical ScrollView can share one finger without either gesture knowing the other exists. Three numbers and one RNGH rule do all the work.

I added a second gesture to this screen after the chart: swipe sideways to step through periods. So now the scrub pan, the page pan and the scroller all want the same touch.

The rule: when a non-simultaneous handler activates, every other handler still in BEGAN gets cancelled. The only question is which one activates first.

The numbers: the scrub needs a 220 ms hold, the page pan needs 24 px of horizontal travel (activeOffsetX), and 12 px of vertical travel fails it outright (failOffsetY). Hold still and the scrub arrives long before your finger drifts 24 px. Flick sideways and the page pan wins in well under 220 ms. Drag downward and the pan fails, so the ScrollView keeps the touch and scrolls as it always did.

The page pan is attached to a plain View that's an ancestor of the ScrollView, not to the ScrollView itself. Two handlers on one native view tag makes arbitration depend on registration order. On an ancestor it's unambiguous. The ScrollView is RNGH's rather than React Native's, so vertical scrolling joins the same arbitration instead of running its own.

These thresholds are load-bearing in a way that's invisible in review. The comment above ACTIVE_OFFSET_X says it out loud: don't lower it, and don't mark either gesture simultaneous with anything.

The Fabric trap that sent me back to the old Animated API

The page transition uses React Native's built-in Animated with useNativeDriver: true, not Reanimated. That looks like a regression. It isn't.

A live Reanimated useAnimatedStyle on a flex: 1 container blanks this screen. The Statistics tab has about eight charts, each resolving its own async query and re-laying-out over roughly three seconds after mount. On one of those re-layouts, Reanimated applies its animated props against a stale measured frame and shoves the whole subtree about 1,600 px off-screen. The tab goes blank with no JS re-render at all, so nothing in the React tree looks wrong.

I root-caused it on device after shipping it. The property being animated is irrelevant: an opacity-only animated style reproduces it. Only removing the animated style from the flex: 1 view fixes it. Lighter screens share the same code path and never reproduce, because their content doesn't repeatedly re-lay-out after mount.

Native-driven Animated doesn't have the bug. The transform is applied by the platform animation module to the view's own node, and is never recomputed from a JS-side measured layout. So the swipe uses it, with a long comment explaining why nobody should modernise it.

Testing a chart without taking a screenshot

Pure geometry means the chart's tests are ordinary unit tests asserting invariants, not pixel snapshots. There are 131 of them across the chart transforms and renderers. A sample of the names:

gradient stop opacity decreases monotonically from top to bottom
a fitted domain contains every data point it was fitted to
an exact midpoint resolves to the earlier point, in both directions
nearestIndex is monotonic: sweeping right never moves the index left
the tooltip never leaves the container, for any anchor
buildGridLines returns nothing for a degenerate domain instead of looping forever

The one I'd recommend to anyone doing a migration like this isn't a geometry test. It's a source-level guard:

const IMPORTS_CHART_KIT =
    /(?:from\s+['"]react-native-chart-kit['"]|require\(\s*['"]react-native-chart-kit['"]\s*\))/;

it('scans a non-trivial number of files (guards against a vacuous pass)', () => {
    expect(allFiles.length).toBeGreaterThan(50);
});

it('no app source imports it', () => {
    const offenders = allFiles.filter((f) =>
        IMPORTS_CHART_KIT.test(readFileSync(f, 'utf8'))
    );
    expect(offenders.map((f) => f.replace(`${ROOT}/`, ''))).toEqual([]);
});

it('the regex really does catch an import (proves the check has teeth)', () => {
    expect(IMPORTS_CHART_KIT.test(`import { LineChart } from '${CHART_KIT}';`)).toBe(true);
    // A comment naming it is fine. This file and several others do.
    expect(IMPORTS_CHART_KIT.test(`// replaces ${CHART_KIT}'s LineChart`)).toBe(false);
});

The dependency is gone from package.json, so a stray import fails at bundle time anyway. But that failure is a confusing "module not found" in Metro. This test states the actual rule, so the next new chart in this repo hears about it in review.

Note the two supporting tests. One proves the file walker found something, so the check can't pass vacuously. One proves the regex has teeth. A guard test that silently stops guarding is worse than no guard, because you stop checking by hand.

What I'd do differently

Check the registry, not your memory of the registry. I called a library unmaintained in a code comment, a changelog and a test docstring. It had shipped a major version two months before I wrote any of them.

The second thing: I spent a while theming around the library before replacing it. Colour props, custom dot renderers, wrappers to fight the sizing. All of it was thrown away.

The heuristic I'd use now has two parts. If two consecutive feature requests need the library to change its geometry or its gesture handling, stop theming and measure how much of the library you actually use. And before you write the word "unmaintained" anywhere, open npm.

Open question, and I'd genuinely like other opinions. I kept the scrub on the JS thread because the readout is React state. If you've moved this kind of scrub fully into a worklet with a shared value driving the SVG cursor, was the complexity worth it on a mid-range Android device? Or is 60 Hz on the JS thread plenty for a gesture this coarse?

The app is open source if you want to read the whole thing: github.com/Antimatter543/mood-tracker. It's on Google Play too.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

Supabase vs Firebase: Which Should You Use in 2026

Diven Rastdus — Wed, 02 Sep 2026 10:09:23 +0000

Pick Supabase if your data is relational or you're adding AI features. Pick Firebase if you're building an offline-first mobile app that lives inside Google's ecosystem. That's the short answer, and for most projects it's the whole answer.

The long answer is the rest of this post. The two backends made opposite bets about how your data should be shaped. That one choice leaks into your auth, your bill, and how hard it is to leave later.

I've shipped four consumer apps to production on Supabase over the last year. I picked it on purpose, and I've also hit its sharp edges, so this is a comparison written from scars, not from a features page.

The data model is the actual decision

Everything else follows from one choice: relational or document. Supabase is managed Postgres, so your data is tables with real foreign keys, joins, and transactions. Firebase's Firestore is a NoSQL document store, so queries are shallow and cannot traverse relationships without extra reads or denormalized copies.

Here is what that difference feels like in code. In Supabase you ask for a user and their posts in one query:

select users.name, posts.title
from posts
join users on users.id = posts.author_id
where users.id = '...';

In Firestore you fetch the user, then loop and fetch each related document, or you duplicate the user's name onto every post so you never have to join. Both work. One of them turns into a maintenance tax as your data grows.

Firebase noticed this pain and shipped Data Connect (now Firebase SQL Connect), a managed Cloud SQL Postgres service with a GraphQL layer on top. It closes the "Firebase cannot do joins" gap. The catch: you're consuming a Google-managed endpoint through Firebase APIs, not owning a Postgres database the way you do on Supabase.

Auth and access control: RLS versus Security Rules

Both platforms give you email, Google, GitHub, Apple, and phone sign-in out of the box. The real difference is where you write your access rules.

Supabase puts them in the database with Postgres Row Level Security. A policy is SQL, and it runs no matter which client hits the table:

create policy "users read own rows"
on documents for select
using ( auth.uid() = owner_id );

Firebase puts them in a separate rules file that guards the Firestore API:

match /documents/{id} {
  allow read: if request.auth.uid == resource.data.ownerId;
}

Neither is wrong. RLS keeps the rule next to the data, which I like because there is one source of truth. Firebase's rules are easier to read on day one but live away from your schema. Both platforms also support anonymous auth for "try before you sign up" flows. On Supabase, anonymous users even carry an is_anonymous claim you can gate an RLS policy on.

Pricing: flat-ish versus pay-per-read

This is where teams get surprised. Supabase is mostly a flat subscription. Firebase is metered by usage, and metered bills are the ones that spike.

Supabase gives you two free projects (500 MB database, 50,000 monthly active users). Then the Pro plan is 25 dollars a month, with a 10 dollar compute credit that covers a small instance. Most early apps sit at exactly 25 dollars until they scale.

Firebase's Spark plan is free with daily caps (50,000 Firestore reads, 20,000 writes). Above that you move to Blaze, which bills per operation: roughly 0.03 dollars per 100,000 reads and 0.09 dollars per 100,000 writes, with prices varying by region. Reads are the cheap part. That still sounds tiny until a chatty client re-reads a collection on every screen and your read count runs away from you.

The mental model: Supabase costs are predictable and driven by compute and egress. Firebase costs are driven by how your app reads and writes, which is easy to underestimate before launch.

One Supabase gotcha you must know: free projects pause after about a week of inactivity, and a paused project's subdomain stops resolving. It bit me once on a low-traffic app. Keep a free project warm with a scheduled ping, or put anything real on Pro.

AI and vector search

If you're building anything with embeddings, Supabase has the cleaner story. Its pgvector support means your embeddings, your application data, and your access policies all live in the same Postgres database, and you query them with plain SQL:

select id, content
from docs
order by embedding <-> '[0.1,0.2,0.3]'::vector
limit 5;

That is RAG without a second datastore to sync. Firebase answers with AI Logic for Gemini integration and vector search through extensions, which works but keeps the pieces more separate. For AI-heavy apps, "same database" is a real advantage.

Lock-in: how hard is it to leave

Supabase is open source and runs on standard Postgres, so leaving is recoverable in weeks. You can even self-host the whole stack. Firebase is Google-managed with proprietary APIs, so leaving is structural and closer to months of work. If optionality matters to you, weight this heavily.

So which one?

Choose Supabase when your data is relational, you want full SQL, you're adding AI or vector features, or you want the option to self-host. Choose Firebase when you're building an offline-first mobile app, or you want realtime sync and client caching with almost no setup. It also fits if you already live in Google's stack with Analytics, Crashlytics, and FCM.

For my apps the deciding factors were relational data and pgvector, so Supabase won. If I were shipping a purely offline-first app tomorrow, I'd give Firebase an honest look for its client-side sync alone. The best backend is the one whose default shape matches your app's default shape.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

The TypeScript Gotcha That Silently Breaks Production (And How to Fix It)

Diven Rastdus — Mon, 31 Aug 2026 10:09:25 +0000

TypeScript's most expensive gotcha: it checks types at compile time, but your data shows up at runtime. Those two moments never meet. The compiler validates the shape you declared, not the bytes the network delivered, so code that typechecks clean and passes CI can still throw Cannot read properties of undefined the first time a real user hits it.

I've shipped this bug. A backend quietly dropped a field, the frontend still compiled and rendered fine in CI, and it blew up in production the moment a real account without that field loaded. You've probably lived some version of it. Here's exactly why it happens and how to stop it.

The two-minute version

Types are erased before your code runs. tsc reads your annotations, checks them against each other, then deletes every last one and emits plain JavaScript. At runtime there is no User type, no string, no number guarantee. There is only whatever your API, your JSON.parse, your environment variables, and your database actually handed you.

That means a type is a promise you make to the compiler. It is not a promise the outside world keeps.

Watch it crash

Here is a User and a value that "is" a User:

interface User {
  id: number;
  name: string;
  email: string;
}

// This actually came from an API that returned { id: 1, name: "Ada" }
// (no email field, a backend change nobody told the frontend about)
const raw: unknown = JSON.parse('{"id":1,"name":"Ada"}');
const user = raw as User;         // compiler: "looks good to me"

console.log(user.email.toLowerCase()); // 💥

Run tsc --strict --noEmit on that. It passes. Zero errors. Then run it:

TypeError: Cannot read properties of undefined (reading 'toLowerCase')

The as User is the trap. A type assertion doesn't check anything. It's you telling the compiler "trust me, stop looking," and the compiler happily obeys. The moment the real data disagrees with your assertion, you get a runtime crash with a stack trace pointing at the symptom, three functions away from the actual lie.

Every one of these is the same gotcha wearing a different hat:

const data = await res.json(): res.json() returns Promise<any>, and any is a hole in the type system that swallows every check downstream.
JSON.parse(...): also any. Same hole.
process.env.PORT: typed string | undefined, but people Number(...) it or slap a ! on it and forget it can be missing (hello, NaN).
arr[i]: this one is worse, because it lies by default.

The one that lies by default

const names: string[] = ["Ada", "Alan"];
const third = names[2];           // TypeScript says: string
console.log(third.toUpperCase()); // undefined at runtime → 💥

names[2] is typed string. At runtime it is undefined. TypeScript, by default, assumes every array index is populated, which is optimistic to the point of being wrong. Turn on one flag:

// tsconfig.json
{
  "compilerOptions": {
    "noUncheckedIndexedAccess": true
  }
}

Now the same line becomes a compile error:

error TS18048: 'third' is possibly 'undefined'.

The bug moved from your production logs to your editor. That is the whole game: pull the failure earlier in time, from a paged 2am incident to a red squiggle you fix before you commit.

The fix: validate at the boundary

The mental model that fixes this permanently: trust types inside your program, never at its edges. Every place data enters from the outside world (network, disk, JSON.parse, env, form input) is a boundary, and a boundary needs a runtime check, not a compile-time assertion.

You don't need a library for this. A type guard is a plain function that returns a special boolean:

interface User { id: number; name: string; email: string; }

function isUser(v: unknown): v is User {
  return (
    typeof v === "object" && v !== null &&
    typeof (v as any).id === "number" &&
    typeof (v as any).name === "string" &&
    typeof (v as any).email === "string"
  );
}

const raw: unknown = JSON.parse('{"id":1,"name":"Ada"}'); // no email
if (!isUser(raw)) {
  throw new Error("API returned a shape we don't trust");
}
// Past this line, `raw` is a real User: checked, not asserted.
console.log(raw.email.toLowerCase());

Now the failure happens at the boundary, with a message that names the actual problem ("API returned a shape we don't trust"), instead of a TypeError deep inside a render function. The v is User return type tells the compiler that inside the if, the value is narrowed to User. No as needed after the guard, because you earned the type instead of asserting it.

For anything bigger than a couple of fields, reach for a schema validator like Zod or Valibot. They generate both the runtime check and the static type from one definition, so the two can't drift apart:

import { z } from "zod";

const User = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().email(),
});
type User = z.infer<typeof User>;

// throws a precise, field-level error if the API lied
const user = User.parse(await res.json());

One source of truth. The static type and the runtime guard are the same object.

The takeaway

TypeScript is a compile-time tool doing a compile-time job extremely well. It was never going to check the network for you, because the network doesn't exist when it runs. The gotcha is not a TypeScript flaw. It is a mismatch between where you think the checking happens and where it actually happens.

Three moves close the gap for good:

Ban as on external data. If it came from outside your program, assert nothing.
Turn on noUncheckedIndexedAccess (and strict, if you somehow still have not).
Validate every boundary with a type guard or a schema, so the type you trust inside is the shape you verified at the edge.

Do that, and the class of bug that typechecks clean and crashes in production stops existing.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

Prompt Chains vs AI Agents: Which Should You Use in 2026

Diven Rastdus — Fri, 28 Aug 2026 10:11:27 +0000

Use a prompt chain when you can name the steps before you run them, even if there are several. Reach for an agent only when the model has to look at each result and decide its own next step from something it cannot predict. Most tasks people hand to an "agent" are the first kind. Swapping a chain for an agent there is how you turn a predictable two-second pipeline into a 30-second, many-times-the-cost, hard-to-debug loop.

I run a production system that is almost entirely automated. It spawns subagents, calls models hundreds of times a day, and ships real work. The surprising part: most of it is not agents. It is plain code calling single LLM calls at the right moments. The agent loops are a small, deliberate minority, and every one of them earns its place. Here is how I decide.

What actually separates a chain from an agent?

A chain is a function you wrote; an agent is a loop the model drives. That's the whole distinction, and it's the one people skip.

In a prompt chain, your code owns the control flow. You decide the order, the branches, and where each model call goes. An agent hands that control flow to the model. The LLM decides what to do next, does it, looks at the result, and decides again until it thinks it's done. That autonomy is powerful and expensive. You trade determinism for the ability to handle problems whose shape you do not know ahead of time. The simplest chain of all is a single call, so start there and climb only when you must.

from anthropic import Anthropic
client = Anthropic()

# Single call: you own the control flow.
def classify(ticket: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=20,
        messages=[{"role": "user",
                   "content": f"Classify this ticket as bug/billing/other:\n{ticket}"}],
    )
    return msg.content[0].text.strip()

That function is boring, and boring is the point. It runs in one round trip, costs one set of tokens, and returns the same shape every time. You can unit-test it, cache it, and reason about it.

When does a single call win? (default here)

A single call wins whenever the task is one transformation and the context fits in the prompt. Classification, extraction, summarization, rewriting, translation, structured-data generation, sentiment, routing: these are single calls, and dressing them up as agents only adds failure modes.

Three reasons the single call is the default:

Cost. An agent that takes five internal steps sends roughly five times the tokens, and every step re-sends the growing history. A ten-step agent can cost twenty times a single call for the same answer. Prompt caching claws some of that back, since cache reads run about ten times cheaper, but you still pay for every fresh loop.
Latency. Each loop iteration is a full round trip. One call is one round trip. Users feel the difference between 300ms and 15 seconds.
Debuggability. When a single call is wrong, you read one prompt and one response. When an agent is wrong, you replay a branching transcript and guess which of nine decisions went sideways.

If you can name the exact steps in advance, you don't need an agent. You need code.

When does an agent earn its complexity?

An agent earns its keep when the number of steps is unknown, the path branches on results you cannot predict, and the model needs tools to act on the world. Think "investigate this failing test until you find the cause," not "summarize this text."

The tell is uncertainty about the path. A coding agent does not know how many files it must read before it finds the bug. A research agent does not know which search will surface the answer. That's real agent territory, because a fixed script cannot encode a path that depends on what the model learns mid-task.

# Agent: the MODEL owns the control flow. Note the while loop.
def agent(goal: str, tools: dict) -> str:
    messages = [{"role": "user", "content": goal}]
    for _ in range(10):  # a hard cap is not optional
        resp = client.messages.create(
            model="claude-sonnet-5", max_tokens=1024,
            tools=[t["schema"] for t in tools.values()],
            messages=messages,
        )
        if resp.stop_reason != "tool_use":
            return resp.content[-1].text  # text is the last block when thinking is off
        # Claude can return several tool_use blocks at once (parallel tools),
        # so collect every result and append ONE user turn. Splitting them into
        # separate messages is the bug everyone ships first.
        messages.append({"role": "assistant", "content": resp.content})
        results = []
        for block in resp.content:
            if block.type == "tool_use":
                output = tools[block.name]["run"](**block.input)
                results.append({"type": "tool_result",
                                "tool_use_id": block.id, "content": str(output)})
        messages.append({"role": "user", "content": results})
    return "hit step limit"

Look at what the loop buys you and what it costs. It buys adaptation: the model can read a file, decide it needs another, and keep going. It costs you a hard step cap, a growing context window, tool-error handling, and a transcript you have to trust. You take that trade only when the adaptation is the whole point.

The prompt chain most people mislabel as an agent

Between "one call" and "full agent" sits the option that solves 80% of the hard cases: a prompt chain where your code orchestrates several calls. You keep the control flow. The model just fills in the smart parts.

# Fixed workflow: known steps, deterministic order, no autonomy.
def triage(ticket: str) -> dict:
    category = classify(ticket)                      # call 1
    if category == "billing":
        summary = summarize_for(ticket, team="finance")   # call 2a
    else:
        summary = summarize_for(ticket, team="eng")       # call 2b
    return {"category": category, "summary": summary}

This is a prompt chain, and it's not an agent. You know there are exactly two calls. You know the order. The branch is a plain if, not a model decision. You get the intelligence of the model with the reliability of code, and you can test every path. When people say "we built an agent" and it works great in production, this is usually what they actually built.

The decision, in one pass

Walk the tree in the diagram top to bottom and stop at the first match:

One well-defined transformation, context in hand? Single call. Do not overthink it.
Multiple steps, no tools, order known? Prompt chain. Code the steps.
Steps known, tools involved, path fixed? Fixed workflow. Code owns the flow.
Path genuinely unknown until the model runs? Agent. Cap the loop and watch it.

The bias should point up the list, not down. Every rung down adds cost, latency, and surface area for bugs. Start at the top and only descend when the task forces you to.

The takeaway

Agents are not an upgrade to a prompt chain. They are a different tool with a different price tag. In 2026 the fastest way to a slow, expensive, flaky feature is to reach for an agent when a chain would do. Ask one question before you build: do I know the steps in advance? If yes, you want a chain, not autonomy. If no, and only if no, you want an agent, and you want a step limit on it.

The best "agentic" systems I have shipped are mostly not agents. They are boring chains with a few smart calls in the right places, and one or two real loops where the path is truly unknown. Boring scales. Autonomy is the exception you spend deliberately.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or theagentthatcould@gmail.com.

Get the next one in your inbox → subscribe at astraedus.dev.

DEV Community: Diven Rastdus

5 New Postgres 19 Features in 2026 (And 2 That Got Pulled Before Release)

1. INSERT ... ON CONFLICT DO SELECT ends the get-or-create dance

2. IGNORE NULLS finally works in window functions

3. WAIT FOR LSN gives you read-your-writes on a replica

4. REPACK CONCURRENTLY rebuilds a bloated table without the long lock

5. pg_plan_advice: plan hints, the sanctioned kind

The 2 that got pulled before release

SQL/PGQ graph queries (reverted September 7)

FOR PORTION OF temporal updates (reverted September 15)

Defaults that change under you

What to do this week

How to Give Your App a Review Monitor That Actually Works (Google Play and App Store, Only New Reviews)

Why the stores' own tools are not enough

Part 1: where the reviews actually come from

Part 2: the de-duplication key is the whole product

Part 3: don't believe an empty answer

Part 4: deliver to a webhook, not a dashboard

Running it daily with no server

The takeaway

TypeScript vs JSDoc vs JavaScript: Which Should You Use in 2026

What changed in 2026?

When does TypeScript pay for itself?

When is plain JavaScript the right call?

What about the middle: JSDoc and @ts-check?

The decision rule for 2026

5 Production Failures AI Coding Agents Cause (And the Checks That Catch Them)

1. The permission that was requested but never declared

2. The transaction that wrapped nothing

3. The tests that defended the bug

4. The suite that collected zero tests

5. The build that asserted the input, not the artifact

The pattern under all five

5 New Python 3.15 Features in 2026 (And 2 I'm Still Waiting For)

1. lazy import makes slow CLI startup a solved problem

2. Unpacking works inside comprehensions

3. frozendict is a built-in

4. A profiler that attaches to a live process

5. sentinel kills the object() trick

The smaller wins I already use

What I'm still waiting for

What to do this week

How MCP Actually Works: The Protocol Behind Every AI Agent Integration

What MCP actually is

What changed in the current revision

Two transports, and only two

What a tool definition actually is

The round trip of one tool call

The parts that only break in production

Tool descriptions are attack surface

The takeaway

Building a Real-Time Dashboard with Python and FastAPI (No WebSockets)

Why not WebSockets?

Fan out with one bounded queue per client

Start the producer with lifespan, not on_event

The endpoint, and what a frame actually looks like

The browser needs nine lines

The four things that silently break (hanging tests, dead producers, nginx, and the six-connection cap)

Bound the queue, drop the oldest

How to Give Your AI Agent a Context Budget That Actually Works

Why does an AI agent get worse the longer it runs?

What is a context budget?

Rule 1: Cap the hot layer, and let a script enforce it

Rule 2: Retrieve instead of re-reading

Rule 3: Make the warm layer someone else's problem

Can the API clear old context for me?

Rule 4: Keep durable state on disk, not in the conversation

Does prompt caching solve this instead?

The takeaway

How I replaced react-native-chart-kit with 1,355 lines of react-native-svg

What was actually wrong with the library chart

The part where I was wrong about the library

Split the geometry out before you draw anything

Colour that carries information

Hold to scrub, tap to expand

Two Pan gestures, one finger

The Fabric trap that sent me back to the old Animated API

Testing a chart without taking a screenshot

What I'd do differently

Supabase vs Firebase: Which Should You Use in 2026

1. `lazy import` makes slow CLI startup a solved problem

3. `frozendict` is a built-in

5. `sentinel` kills the `object()` trick