DEV Community: Diven Rastdus

5 AI Agent Features That Define 2026 (And 2 I'm Still Waiting For)

Diven Rastdus — Wed, 19 Aug 2026 10:12:42 +0000

The five features that define AI agents in 2026 are a shared tool standard (MCP), prompt caching, computer use, background subagents, and agent-to-agent messaging. None of them are the model itself. They are the plumbing that turns a clever text generator into something that does actual work.

I run agents in production every day. For most of 2024 an "agent" meant a model stuck in a while loop, and it broke the moment it touched the real world. In 2026 that stopped being true, and it had almost nothing to do with the models getting smarter. It was the layers underneath.

Here are the five that changed how I build, and the two I'm still waiting on.

1. MCP became the universal tool layer

MCP turned connecting an agent to a tool into one open standard, instead of a bespoke integration per vendor. That's the single biggest shift of 2026. The Model Context Protocol (MCP), which Anthropic released in November 2024, does for agent tools what USB did for peripherals: write the tool once, and any model can call it.

The adoption is not a rumor. OpenAI adopted MCP in March 2025. In December 2025 Anthropic donated it to the Agentic AI Foundation, a new fund under the Linux Foundation, so it's now vendor-neutral infrastructure rather than one company's project. A tool server is tiny:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Return today's forecast for a city."""
    return fetch_weather(city)

mcp.run()

That server now works with Claude, ChatGPT, and anything else that speaks MCP. Before this, I wrote the same tool three times. Now I write it once and forget which model is on the other end.

2. Prompt caching made the agent loop affordable

Agents got cheap enough to run in loops because providers now let you reuse a cached prompt prefix for roughly a tenth of the price. An agent re-sends the same giant system prompt (tools, instructions, context) on every single turn. Paying full price for that on turn 40 was the hidden tax that killed long-running agents.

By 2026 all three major providers discount cached input by up to 90%. On Anthropic you mark the stable part of the prompt once:

client.messages.create(
    model="claude-sonnet-5",
    system=[{
        "type": "text",
        "text": BIG_SYSTEM_PROMPT,          # tools + instructions + docs
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "do the next step"}],
)

You pay a small write premium the first time (1.25x on the 5-minute tier), then every later turn reads that prefix at 0.1x. A 40-turn agent run that used to feel reckless now costs pocket change. This is the feature nobody puts on a launch slide, and it's the one that quietly unlocked everything else.

3. Computer use turned agents into hands, not just mouths

Agents can now see a screen and operate it directly, so any app with a UI is reachable even when it has no API. Claude's computer-use launch in October 2024 was the inflection point. Anthropic's own benchmarks show the jump: computer-use task completion on OSWorld climbed from about 15% at launch to over 70% in 2026.

You give the model a screen and a set of physical actions:

tools = [{
    "type": "computer_20250124",   # use the current tool version from the docs
    "name": "computer",
    "display_width_px": 1280,
    "display_height_px": 800,
}]
# The model replies with actions: screenshot, click(x, y), type("...").
# You execute each one, send back a fresh screenshot, and repeat.

I use this to drive a real browser with our own logins. It reads the page, decides what to click, and adapts when the layout moves. That's the difference from old RPA scripts, which shattered the first time a button shifted ten pixels.

4. Background subagents made parallelism the default

The best agent systems in 2026 stopped being one model in one loop and became many agents running at once, in the background. Instead of a human running tasks one after another, you fan out a fleet, each subagent with its own context window and its own tools.

import asyncio

async def run_agent(task):
    # each subagent: isolated context, its own tools, its own model
    return await agent.run(task)

results = await asyncio.gather(*[run_agent(t) for t in tasks])

Both Claude Code and Codex shipped this: Codex spins up parallel cloud sandboxes and returns pull requests, and background sessions now survive a closed laptop. I lean on this constantly. A review that would take one agent an hour of sequential reading becomes ten agents reading in parallel, and I only hold the synthesis in context. Parallelism is free in a digital medium, and 2026 is the year the tools finally made it easy.

5. A2A let agents talk to other agents

A2A is a standard for agents to discover and call each other across vendors, the way MCP standardized tools. It's the newest layer in the 2026 stack. Google's Agent2Agent (A2A) protocol, announced in April 2025 and donated to the Linux Foundation, reached a stable v1.0 in early 2026 with more than 150 organizations backing it.

An agent advertises itself with an Agent Card, a small manifest other agents can read:

{
  "name": "billing-agent",
  "description": "Answers invoice and payment questions",
  "url": "https://api.acme.com/a2a",
  "version": "1.0",
  "capabilities": { "streaming": true },
  "skills": [{ "id": "lookup_invoice", "name": "Look up an invoice" }]
}

MCP connects an agent to tools. A2A connects an agent to other agents. It's early, but the shape of a real multi-agent internet is now visible.

The 2 I'm still waiting for

Durable native memory. Every serious agent I run still fakes memory with a bolt-on: a vector database, or a folder of markdown files I re-inject each session. It works, but it's scaffolding I built by hand. No provider ships memory that survives across sessions and actually generalizes what it learned. Until that's native, "my agent remembers you" is a feature you engineer, not one you turn on.

Trustworthy long-horizon autonomy. Agents are brilliant for twenty steps and drift on step two hundred. Errors compound, the plan wanders, and the only reliable fix is a human checking the work. I still verify every meaningful agent output against a real source of truth, never the agent's own "done." Real autonomy means the agent catches its own drift. We are not there.

The takeaway

The model got the headlines in 2026. The progress that changed my day-to-day was the stack around it: a tool standard, cheap loops, real hands, parallel execution, and agents that talk to each other. You don't need to adopt all five. Pick the one layer that removes your biggest friction (usually MCP or caching) and add it to whatever you're already building. That's where the real gains are hiding.

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 TypeScript Features That Define 2026 (And 2 I'm Still Waiting For)

Diven Rastdus — Wed, 05 Aug 2026 10:22:33 +0000

The biggest TypeScript change of 2026 isn't a new type. It's a new engine. The compiler got rewritten in Go and now type-checks about ten times faster, and Node runs your .ts files with no build step at all. A few of these landed across 5.8 and 5.9 during 2025, but together they're the toolchain I'm actually standing on this year. Here are the five I reach for across our projects, and the two I keep waiting on.

1. The compiler went native, and it's roughly 10x faster

The headline feature of TypeScript 7 is that the compiler is now a native binary written in Go. Microsoft measured a full type-check of the VS Code codebase dropping from 77.8 seconds to 7.5 seconds. That's a 10.4x cut on real code, not a toy benchmark.

The project codename is Corsa, and Anders Hejlsberg (TypeScript's lead architect) is running it. The important part: there's no new type system and no new syntax. The team took the existing checker and ported it, keeping the logic structurally identical. So your types behave the same. The wait just gets shorter.

You can try it today from the preview package:

npm install -D @typescript/native-preview
npx tsgo --noEmit

I ran it on one of our Expo apps. A clean tsc --noEmit took 4.2 seconds; the same check on tsgo took 0.8 seconds. That's about 5x on a small codebase, and the gap only widens on big ones, which is where the VS Code 10.4x comes from. Expect one bump on the way in: tsgo immediately rejected our baseUrl option with error TS5102, because TypeScript 7 removed it. Paths resolve relative to the config file now, so I deleted one line and it passed. From the release candidate onward the native compiler folds back into the normal typescript package and the tsc command, so most projects bump a version and change little else. The one caveat before you migrate: TypeScript 7.0 has no stable programmatic API yet, which is why some tools still lag (more on that below).

2. You can run TypeScript with no build step

TypeScript 5.8 added --erasableSyntaxOnly, which pairs with Node's native type stripping so you can run a .ts file directly. No transpile, no bundler, no dist folder for local scripts.

Node strips the type annotations and runs the rest. That works for almost everything, but a few TypeScript features emit real runtime code and can't be stripped: enums, namespaces with runtime bodies, and constructor parameter properties. The flag catches those at author time so you never ship code Node can't run:

// Both of these now error under erasableSyntaxOnly:
enum Color { Red, Green }          // enums compile to a runtime object

class User {
  constructor(private id: string) {}  // parameter property emits an assignment
}

Turn it on in your config and run the file straight from Node (22.18 and up, on by default in Node 24):

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

node server.ts

The trap: type stripping deletes types and runs the code without checking them. A type error won't stop the program. You still need tsc --noEmit in CI to actually catch mistakes.

3. `import defer` lets you lazy-load a module

TypeScript 5.9 shipped support for import defer, a Stage 3 ECMAScript proposal that delays evaluating a module until you first touch one of its exports. It's a clean win for expensive dependencies you don't always use.

import defer * as heavyAnalytics from "./heavy-analytics.js";

export function trackFirstOpen() {
  // heavy-analytics.js runs only when this line executes,
  // not when the file is imported at startup
  heavyAnalytics.track("app_opened");
}

One rule to remember: only namespace imports (import defer * as x) are allowed. Named and default imports aren't, because the whole point is to avoid evaluating the module up front. I use this for analytics and PDF generation, the code paths most users never hit on a cold start.

4. `--module node20` gives you a target that stops moving

TypeScript 5.9 added --module node20, a stable option that models Node.js 20 behavior and implies --target es2023. The value here is predictability.

The older nodenext setting tracks whatever the latest Node does, so its behavior shifts under you as Node evolves. node20 pins to a known version and stays put, which is exactly what you want in a tsconfig.json you won't touch for a year:

// tsconfig.json
{
  "compilerOptions": {
    "module": "node20"   // stable, and implies "target": "es2023"
  }
}

Small feature, but it removes a class of "it worked last month" surprises in CI.

5. Better defaults and hovers make the editor pull its weight

TypeScript 5.9 reworked tsc --init to emit a lean config instead of a hundred commented-out lines, and it made editor hovers far more useful. This is the quality-of-life bucket, and it matters more than it sounds.

The new tsc --init writes a short, readable file instead of a wall of comments, close to this:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "nodenext",
    "strict": true
  }
}

On top of that, DOM type definitions now carry summary descriptions pulled from MDN, so hovering element.scrollIntoView explains what it does without a trip to the browser. Hovers also got expandable + and - buttons to drill into a deep type instead of squinting at a truncated blob.

The 2 I'm still waiting for

A stable compiler API on the native build. Every one of our repos runs typescript-eslint, and template type-checking for Vue, Svelte, and Astro all lean on TypeScript's programmatic API. TypeScript 7.0 ships without a stable one, so those tools can't run on the native compiler yet. The API is targeted for 7.1, several months out. Until then you get the fast tsc, but your lint and framework checks still ride the old engine.

Nominal (opaque) types. TypeScript is still structural, so two string aliases are interchangeable no matter what you name them. To fake a real distinct type, we hand-roll brands:

type UserId = string & { readonly __brand: "UserId" };
type PostId = string & { readonly __brand: "PostId" };

function getUser(id: UserId) { /* ... */ }
// getUser(somePostId as PostId)  // the brand trick works, but it's a trick

It works, and it has saved us from passing a post id where a user id belongs. But a __brand phantom field is a workaround for a language feature that should exist. Give me a real nominal keyword.

Takeaway

The theme for TypeScript in 2026 is speed and less ceremony, not more type gymnastics. The native compiler makes big codebases feel small again, no-build-step .ts kills a whole tooling layer for scripts, and import defer trims your startup cost. Upgrade when you can, but keep tsc --noEmit in CI as your real safety net, because the fastest features here are the ones that skip type-checking entirely. Fast is only good when it's also correct.

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 React Native App a Memory That Actually Works

Diven Rastdus — Mon, 03 Aug 2026 10:18:45 +0000

A React Native app has three separate kinds of memory, and almost every "my data disappeared" bug comes from storing a value in the wrong one. Once you can name the three tiers and match each piece of data to the right one, "remembering" stops being a mystery and becomes a routing decision.

Here's the problem you'll hit. A user fills out onboarding, sets dark mode, adds three entries, then force-quits the app. They reopen it and everything's gone. Or the softer version: the app launches in light mode for half a second, flashes white, then snaps to the dark theme they actually chose. Both are the same bug wearing different clothes. Something lived in the wrong tier of memory.

Your app has three kinds of memory

A React Native app stores data in three local tiers, and each one survives a different amount of destruction. Above them sits the server, which is the only thing that survives a reinstall.

In-memory state (useState, useReducer, Zustand held in RAM). Fast, but it survives nothing. A reload, a background-kill, or a crash wipes it.
Key-value storage (MMKV, AsyncStorage, expo-secure-store). Small values that survive a restart. Themes, flags, tokens.
Structured storage (expo-sqlite, WatermelonDB). Rows you can query, sort, and read offline. Notes, entries, a synced list.

The server (Supabase or your own API) is the source of truth. Every local tier is a cache of it.

Match each value to the right tier

The right tier for a value comes down to two questions: how much destruction it must survive, and how you'll read it back. A single flag reads differently than a list you sort.

What you are storing	Tier	Store to use
Auth token, API keys	secrets	`expo-secure-store`
Theme, onboarding-done, feature flags	small key-value	MMKV / AsyncStorage
Notes, entries, a list you query	structured records	`expo-sqlite`
The canonical copy shared across devices	source of truth	your server, cached locally

One security note that catches people. AsyncStorage and MMKV aren't encrypted by default, so an auth token doesn't belong there. Secrets go in expo-secure-store, which is backed by the iOS Keychain and Android Keystore.

Why your data disappears: AsyncStorage is async

The most common "data loss" bug isn't lost data at all. It's reading storage a beat after your UI has already rendered with a default value.

AsyncStorage returns a promise. Your component renders once with its initial state, then the saved value arrives and triggers a second render. The user sees the gap.

function useThemePref() {
  const [theme, setTheme] = useState("light"); // default paints first
  useEffect(() => {
    AsyncStorage.getItem("theme").then((saved) => {
      if (saved) setTheme(saved); // real value lands after first paint
    });
  }, []);
  return theme;
}

The user picked dark mode last week. On launch they still see a white flash, then it corrects. The data was never lost. You just read it too late.

Make key-value memory synchronous with MMKV

MMKV reads and writes synchronously, so the value is already there on the very first render. No promise, no await, no flash. Pair it with Zustand's persist middleware and your store rehydrates itself.

import { MMKV } from "react-native-mmkv";
import { create } from "zustand";
import { persist, createJSONStorage, StateStorage } from "zustand/middleware";

const storage = new MMKV();

const mmkvStorage: StateStorage = {
  getItem: (k) => storage.getString(k) ?? null,
  setItem: (k, v) => storage.set(k, v),
  removeItem: (k) => storage.delete(k),
};

export const usePrefs = create(
  persist(
    (set) => ({ theme: "light", setTheme: (theme) => set({ theme }) }),
    { name: "prefs", storage: createJSONStorage(() => mmkvStorage) }
  )
);

Because the read is synchronous, usePrefs.getState().theme is correct on the first paint. The white flash from the AsyncStorage version is gone, and you didn't change a single component.

Gate the first render on hydration

When a tier is genuinely async (SQLite, a network cache), the cleanest fix is to not render the app until its memory has loaded. Hold a spinner until the first read resolves, then mount the tree with real data.

import { useEffect, useState } from "react";
import { ActivityIndicator, View } from "react-native";
import { useSQLiteContext } from "expo-sqlite";

function Root() {
  const db = useSQLiteContext();
  const [prefs, setPrefs] = useState<Prefs | null>(null);

  useEffect(() => {
    db.getAllAsync("select key, value from settings")
      .then((rows) => setPrefs(rowsToObject(rows))); // memory is now warm
  }, [db]);

  if (!prefs) {
    return (
      <View style={{ flex: 1, justifyContent: "center" }}>
        <ActivityIndicator />
      </View>
    );
  }
  return <App prefs={prefs} />;
}

This is exactly what a settings provider backed by expo-sqlite does in our own apps. It shows a spinner while the first query runs, seeds its context with the saved rows, and only then renders the screens. The user never sees a default value flicker into the real one, because the real one was loaded before anything painted.

The takeaway

Storing data in React Native is a routing problem, not a library problem. You're not choosing between AsyncStorage and SQLite in the abstract. You're asking, for one specific value, how much it must survive and how you'll read it back. Answer those two questions and the tier picks itself.

Three rules carry most of the weight. Put each value in the lowest tier that meets its durability and access needs. Never let an async read paint a default first, either make the read synchronous or gate the render on it. And keep the server as the source of truth, with every local tier treated as a cache you can rebuild. Do that and your app remembers exactly what the user expects, every time they come back.

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.

I Built a Practice App Because Every "Duolingo for Music" Kept Failing Me

Diven Rastdus — Sun, 02 Aug 2026 13:34:22 +0000

I've lost track of how many "Duolingo for piano" apps I've downloaded and deleted. Simply Piano, Yousician, a few others I don't remember the names of. Every one of them followed the same shape: score how close your playing matched a reference MIDI file, throw a badge at you, ask for a monthly subscription. None of them ever told me why a passage was hard, or when I was actually ready to move past it. They graded me. They didn't teach me.

So I built the app I actually wanted and put it up for anyone else with the same problem. It's called Music Practice, it covers piano, electric guitar, and drums, it's free, and the code is open. No account needed to use any of it.

The gap I kept hitting

Apps that gamify practice, streaks, XP, song-matching scores, are optimizing for a different thing than learning. They want you to open the app again tomorrow. That's a real goal and I get why it's the business model, but it produces a curriculum that's basically a leveled list: do lesson 4, then 5, then 6, with no visible reason 5 needed 4 first, and no way to tell if you're already past it.

What I wanted instead was something that always knew exactly what I should practice next, and could tell me why, in one sentence, before I drilled it.

A real DAG, not a leveled list

The curriculum is a directed acyclic graph. Every skill node carries its own prerequisites as explicit edges:

export interface SkillNode {
  id: string;                         // "g-t1-power", "p-key-C-scale"
  instrument: Instrument | "shared";
  title: string;
  tier: 0 | 1 | 2 | 3 | 4 | 5 | 6;
  category: SkillCategory;
  prereqs: string[];                  // node ids, the DAG edges
  masteryDrill: string;
  unlock: string;                     // the capability sentence
}

A node's live status resolves from its prereqs plus your progress:

export function resolveStatus(
  nodes: SkillNode[],
  progress: ProgressMap,
): Map<string, SkillNodeStatus>

Locked if a prereq isn't learned yet. Available once every prereq is. In-progress once you've logged reps on it. Learned once you've finished it. nextToLearn() filters for available nodes and sorts by tier, that's the entire "what should I practice tonight" decision. No hand-coded switch statement guessing what unlocks when, just prereq edges getting walked.

Right now the tree has 32 piano nodes, 36 guitar nodes, and 20 drum nodes. Drums is practice-pad only for now, no full kit.

The instrument-agnostic part matters as much as the DAG. Piano, guitar, and drums share one practice engine through an InstrumentModule interface, and each instrument lives in its own lib/<name>/module.tsx that self-registers on import. The only two components that actually know which instrument you're holding are the fretboard/keyboard visual and the tab/staff notation. The skill tree resolver, the review scheduler, the session generator, none of it cares what instrument it's looking at. Adding drums meant a new lib/drums/ folder and one import line, not a rewrite.

Applying the research instead of guessing

Before building the technique-drill and review systems I wrote up a research pass on motor learning, because I didn't want to just intuit what "good practice" looks like. A few of those findings actually made it into the app as testable code, not vibes.

Slow practice builds an accurate motor pattern. Jumping straight to target tempo doesn't. So technique drills ladder tempo up in small steps and only advance after a clean run at the current speed, no slider you can just drag to "hard."

A skill "learned" once and never touched again quietly rots, so REVIEW_INTERVALS_DAYS = [1, 3, 7, 14] brings finished nodes back at expanding intervals instead of letting them vanish the moment you pass them.

And the ear training is honestly gated. The app never quizzes you on a chord progression it hasn't actually taught yet. Your effective ear level is clamped to whatever the skill tree has covered, so an advanced learner who self-reports at onboarding gets trusted, but nobody gets tested on theory they've never seen.

The stack

Next.js 16 and React 19, TypeScript throughout. Tone.js handles audio. VexFlow renders notation. svguitar draws chord diagrams. The skill graph itself, the visual tree on the roadmap page, renders with @xyflow/react and gets laid out with dagre. Nothing exotic, just the right library for each surface.

Storage: local-first, cloud optional

Everything lives in localStorage by default. No account, no login wall, no server round-trip before you can play a note. That felt like the right default for something you open at night, tired, wanting to just start playing.

If you want your progress on a second device, there's an opt-in cloud sync that only activates once you sign in. It's additive, never required, and the local copy stays the source of truth.

What's next

I'm still filling out gaps in the guitar and drum curricula, and there's a batch of pop-song repertoire work queued that needs a real song list before it can ship. But the core loop, tell you what to practice, explain why, ladder the tempo, bring it back later, is live now.

Music Practice is free and open source, live at music.raeduslabs.com. If you use it, even for five minutes, I want to know what confused you or what you wished it did next. Repo's open, issues welcome: github.com/astraedus/piano.

TypeScript vs JavaScript: Which Should You Use in 2026

Diven Rastdus — Fri, 31 Jul 2026 10:22:33 +0000

Use TypeScript for anything you plan to keep past the weekend. Reach for plain JavaScript only for throwaway scripts, quick experiments, and learning the fundamentals. That answer hasn't really changed in years.

What changed in 2026 is that the two oldest reasons to avoid TypeScript both died. Builds got roughly ten times faster, and Node now runs .ts files with no build step at all. So if you've been putting off the decision because TypeScript felt heavy, the tax you were avoiding is mostly gone.

I ship TypeScript across every app I build (React Native, Next.js, small Node services), and I still drop into plain JavaScript a few times a week. Here's where each one actually earns its place now.

They are not two competing languages

TypeScript is not a separate runtime language. It's JavaScript with a type layer that gets erased before your code runs. Every TypeScript project ships as JavaScript underneath.

So "TypeScript vs JavaScript" is really one question: do you want a compiler checking your types while you write, or not? Nothing you write in TypeScript exists at runtime except the JavaScript it compiles down to. That framing explains why every argument below is about writing code, not running it.

The two arguments against TypeScript died in 2026

The classic case against TypeScript was always "the build is slow" and "I need a whole toolchain just to run one file." Both of those are gone as of mid-2026.

First, the compiler got fast. TypeScript 7.0 shipped on July 8, 2026 as a native port of the compiler written in Go (the project was known as Corsa, or tsgo). Microsoft reports 8x to 12x faster full builds; independent benchmarks on type-heavy codebases land closer to 4x to 7x. Either way, the "tsc is slow" complaint that justified skipping types on large projects no longer holds. When you npm install typescript, the Go-native compiler is what you get.

Second, you no longer need a build step to run TypeScript locally. Node strips types natively now, and it's stable and unflagged in the current Node 24 LTS:

# No tsc, no ts-node, no bundler. This just runs.
node script.ts

Deno and Bun have run .ts files directly for years, and Deno even type-checks as part of the run. Node caught up and made it the default.

One caveat matters here. Node only strips "erasable" syntax. Enums, namespaces with runtime values, parameter properties (constructor(private x: string)), and decorators are not plain types, so Node refuses to run them. More on that gotcha below.

When plain JavaScript still wins

Plain JavaScript is the right tool when the code won't live long enough to earn a type system.

A throwaway script or a one-off piece of automation.
A tiny prototype you fully expect to delete.
Learning the language, where types add ceremony before the concepts land.
A no-build <script> snippet dropped straight into a browser page.

For those, a type checker is friction with no payoff. You're optimizing for speed of thought, not for the person who maintains this in six months, because there is no such person.

There's also a middle ground people forget. You can get real type checking in a plain .js file with JSDoc and a single comment, no .ts extension and no build step:

// @ts-check

/**
 * @param {number} price
 * @param {number} taxRate
 * @returns {number}
 */
function withTax(price, taxRate) {
  return price + price * taxRate;
}

withTax(10, "0.1"); // Editor flags this: string is not assignable to number

This is a fully supported TypeScript feature, not a hack. Svelte's core was famously typed this way for years, with JSDoc instead of .ts files.

When TypeScript wins (which is most of the time)

If more than one person, or more than one week, will touch the code, TypeScript wins.

Refactors stop being scary, because the compiler finds every call site you broke.
Public APIs and libraries document themselves through their types.
Teams stop guessing what shape an object is, because the answer is in the editor.
AI-assisted coding gets a safety net. A 2025 study found that 94% of compile errors in AI-generated code were type-check failures, which is exactly the class of mistake types catch instantly.

The ecosystem has already voted. GitHub's Octoverse 2025 report put TypeScript at the top: in August 2025 it became the most-used language on GitHub by monthly contributors, passing Python. New projects rarely make the choice by hand anymore, because Next.js, Astro, SvelteKit, and Angular all scaffold TypeScript by default. For most new work, TypeScript is simply what you get unless you opt out.

The 2026 decision, in one view

Here's the whole thing on one page.

Two gotchas before you jump

Two 2026 traps before you upgrade.

The first is TypeScript 7 tooling lag. The Go-native compiler does not expose a stable programmatic API yet (that's targeted for 7.1). Tools that import the compiler and call into it are not guaranteed to work against 7.0 on day one. That includes typescript-eslint and the template checkers behind Vue, Svelte, and Astro. If your stack depends on those, pin the previous TypeScript 6 line for that tooling until the API stabilizes.

The second is Node's erasable-syntax limit. Because node script.ts only strips types, any TypeScript feature that emits runtime code will throw. Turn on a compiler flag so you catch it while type-checking instead of at runtime:

{
  "compilerOptions": {
    "erasableSyntaxOnly": true
  }
}

With that set, tsc warns you the moment you reach for an enum or a parameter property that Node cannot run.

The takeaway

Default to TypeScript in 2026, and keep plain JavaScript for genuinely short-lived code. The two changes this year (a ~10x faster compiler and native .ts execution) removed the friction that made "just use JavaScript" a reasonable call for real projects.

Can't add a build step? You're still not stuck with untyped code. Add // @ts-check and a few JSDoc comments and you keep most of the safety net. Otherwise, start it typed. The friction is what people were really voting against, not the types.

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 5 Things That Silently Break AI Agents in Production

Diven Rastdus — Mon, 27 Jul 2026 10:17:51 +0000

Your AI agent works in the demo because the demo runs once, on a clean input, while you watch. Production is thousands of runs, on messy inputs, with nobody watching. The gap is almost never the model's reasoning. It's five plumbing failures that stay invisible until they cost you a bad night.

I run a fleet of agents unattended, every day. The first time I left one going overnight, it reported a clean run. Every step logged "success." The actual work was half-finished, and it had burned a small fortune getting there. None of the five failures below throw an error. They quietly produce a wrong result and hand it to the next step, which trusts it completely.

Here is the map. The same loop that shines in a demo has five silent failure points once it runs for real.

1. The agent forgets everything between steps

The agent's plan lives only in the model's context window, and that window gets summarized, truncated, or reset on any long run. When it does, the plan goes with it. Then the agent redoes work it already finished, or flatly contradicts itself. The demo never hits this because the demo is short.

Treat the context window as a cache, not your source of truth. The durable state lives in a store, and every step loads it back before it does anything.

// BAD: the plan is stuffed into a prompt string. One summarization and it's gone.
const prompt = `Goal: ${goal}. Done so far: ${doneList}. Next?`;
const next = await model.decide(prompt);

// GOOD: state lives in a store. Every step LOADS it, then saves.
type AgentState = { goal: string; done: string[] };

async function step(runId: string) {
  const state = await loadState(runId);        // re-hydrate from the store, every step
  const decision = await model.decide(state);  // the model sees ALL prior state
  await saveState(runId, { ...state, done: [...state.done, decision.action] });
  return decision;
}

The helpers here (loadState, saveState, and their friends further down) are yours to implement. The pattern is the point. If your agent has to remember something across steps, that memory belongs on disk or in a row, not in the prompt.

2. It trusts its own "done"

The agent believes its own report. The model says "I wrote the file," your code marks the task complete, and nobody checked the disk. But success usually means the run finished, not that the artifact exists. When the model authored that field itself, it means even less.

So check the world, not the claim. And check it well, because a stale artifact from a previous run will pass a lazy check.

// BAD: trust the model's word.
const result = await agent.run("write report.pdf");
markComplete(result);            // result.success means "the run ended", not "the file is there"

// GOOD: clear any stale copy, then prove the new one exists.
await rm("report.pdf").catch(() => {});
await agent.run("write report.pdf");
const stat = await fs.stat("report.pdf").catch(() => null);
if (!stat || stat.size === 0) {
  throw new Error("agent reported done, but report.pdf isn't there");
}

That one rule, "a claim is not a fact," kills a whole class of confabulation bugs. The agent can be wrong without meaning to, so your code shouldn't take it at its word.

3. A tool call "succeeds" but did nothing

A tool can return without an error and still do the wrong thing, or nothing at all. An HTTP 200 can mean "accepted but queued," "partial write," or "no-op." An exit code of 0 means the program said it succeeded: curl without -f exits 0 on a 404, and grep exits 1 when it simply found nothing. And fetch doesn't reject on a 500 or a 403 either, only on a network failure, so "no exception" is a weaker signal than it looks.

Validate the effect you wanted, not the status you got back. Read the write back out and confirm it landed.

// BAD: no exception, so it worked, right? (fetch resolves on 500 and 403 too.)
await fetch(url, { method: "POST", body });

// GOOD: check the status, then read the record back.
const res = await fetch(url, { method: "POST", body });
if (!res.ok) throw new Error(`POST failed: ${res.status}`);
const { id } = await res.json();
const saved = await fetch(`${url}/${id}`).then(r => (r.ok ? r.json() : null));
if (saved?.status !== "written") {
  throw new Error("write returned 200 but did not persist");
}

On an eventually-consistent store, poll with a short backoff instead of reading once, or a write that really landed can still 404 on the immediate read-back. I once watched an agent post the same update fifteen times: each call returned 200, a downstream queue silently dropped it, so the agent re-checked, saw nothing, and posted again.

4. Small errors compound into a broken chain

The fourth failure is pure math. Assume steps fail independently, which is optimistic, and a step that works 95% of the time still poisons the chain. 0.95 ** 10 is 0.60. Four in ten full runs now fail somewhere, and a three-step demo hid it completely.

Retries buy most of it back, so build the chain to absorb flakiness: retry, dedupe, checkpoint.

const reliability = 0.95 ** 10; // 0.5987... not "reliable" across ten steps

async function safeStep(fn: () => Promise<any>, key: string) {
  if (await alreadyDone(key)) return getResult(key);  // dedupe: skip work already recorded
  const out = await withRetry(fn, 3);                 // absorb transient flakiness
  await recordResult(key, out);                       // checkpoint so a failure resumes here
  return out;
}

Three attempts at 95% is 99.99% per step, which is 99.88% across the ten. But that dedupe lives at the orchestrator level only. The downstream operation still has to be idempotent on its own: pass an idempotency key to the payment or API provider, because a crash between the call and the checkpoint will run it twice, and twice means double-charge, double-send, double-write.

5. The loop never stops (and neither does the bill)

The fifth failure is the runaway loop. while (!done) { await agent.step() } is one bad plan away from looping forever, and every iteration is a paid API call. Nobody notices in the demo because the demo finishes. Unattended, it can spin for hours and hand you an invoice instead of a result.

Put hard ceilings on it that fail closed. When a limit trips, the agent stops and tells you, rather than grinding on.

class BudgetError extends Error {}

// A step cap AND a token/cost cap. Both fail closed.
let steps = 0, tokens = 0, done = false;
while (!done) {
  if (++steps > 25)      throw new BudgetError("step budget exceeded");
  if (tokens > 200_000)  throw new BudgetError("token budget exceeded");
  const out = await agent.step();
  tokens += out.usage.total_tokens ?? 0;   // field name is provider-specific (see below)
  done = out.done;
}

Watch that usage field. OpenAI gives you total_tokens; Anthropic gives you input_tokens and output_tokens and no total. Read the wrong one and tokens becomes NaN, every NaN > 200_000 is false, and your cap silently never fires. That is this whole article in one line: no error, wrong result. And notice the throw is a BudgetError, not a plain one. If a budget throw gets swallowed by the retry wrapper from failure #4, you re-burn the whole budget three times. That is the exact bill this guard exists to prevent.

The pattern under all five

One idea ties these together: the model proposes, deterministic code disposes. Treat every model output as untrusted input to an ordinary program. Verify it against the real world. Put hard limits around the loop. Keep the LLM for the fuzzy judgment it's good at, and keep the guarantees in plain code that can't hallucinate.

Here is the ship checklist:

[ ] State lives in a store, loaded back every step, not in the context window
[ ] Every "done" is verified against the source of truth
[ ] Tool calls are checked by effect, not by status code
[ ] Steps are deduped and retried; the downstream op is idempotent
[ ] The loop has a step cap and a real token/cost cap (mind the field name)

That list is the whole difference between a thing that demos well and a thing you can actually walk away from.

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 AI Agent Tool Use That Actually Works

Diven Rastdus — Fri, 24 Jul 2026 10:13:12 +0000

Your AI agent works in the demo and breaks in production for one reason, and it's almost never the model's reasoning. It's the tool calls. The model picks the right tool, then hands it a hallucinated argument, or it trusts a tool result that quietly failed. Reliable tool use isn't a smarter model. It's a discipline: treat every tool call the model makes as untrusted input. Validate it against a schema before you run it, then verify the result before the agent believes it.

I run an agent whose entire job is tool calls. It publishes posts, sends email, pushes git, drives a browser, mostly with no human watching. A plausible-but-wrong call there isn't a shrug in a chat window. It's a real email to the wrong person. So this problem is my whole day, and the fix below is what turned a flaky demo into something I can leave running.

The failure nobody catches in the demo

The classic tool-use bug is the model filling in a blank it should have refused to fill. Take a request like "schedule a meeting with Sarah next week." The model doesn't know which Sarah, which timezone, or which 30-minute slot, so it guesses. In a chatbot that guess is invisible. Wire the same model to a send_calendar_invite tool and the guess becomes a real invite to the wrong Sarah at 3am her time.

The model isn't being dumb. It picked the right tool. The system around the tool just believed a value it never should have trusted. That's the gap, and you close it with four cheap checkpoints between "the model wants to call a tool" and "the agent acts on the result."

1. Design tools the model can't misuse

Narrow, single-job tools beat broad API wrappers on reliability. A generic tool hands the model too much rope; a narrow one leaves almost nothing to hallucinate into.

// Broad and dangerous: the model writes the SQL, you run whatever it invents.
queryDatabase(sql: string): Row[]

// Narrow and safe: one job, typed inputs, nothing to guess into.
getInvoiceById(invoiceId: string): Invoice

queryDatabase lets a wrong guess drop a table. getInvoiceById can only ever fetch one invoice by one id. Every tool you expose is attack surface for a confident mistake, so keep each one boring and specific.

2. Validate arguments before you execute

Provider structured outputs (OpenAI's JSON schema mode, Anthropic tool use) guarantee the shape of the arguments, not the correctness of the values. Well-formed JSON can still say "invite bob@typo" or a duration of 900 minutes. So validate the arguments yourself, and treat them as untrusted input even when they parse.

import { z } from "zod";

// The schema is the contract. The model's arguments are untrusted until they pass it.
const SendInvite = z.object({
  attendeeEmail: z.string().email(),
  startsAt: z.string().datetime(),       // ISO 8601. No "next week" left to guess.
  durationMins: z.number().int().min(5).max(240),
});

function validateArgs(rawArgs: unknown) {
  const parsed = SendInvite.safeParse(rawArgs);
  if (!parsed.success) {
    const reason = parsed.error.issues
      .map((i) => `${i.path.join(".")}: ${i.message}`)
      .join("; ");
    // Return the reason. Do NOT throw. The model reads this and fixes the call.
    return { ok: false, error: reason };
  }
  return { ok: true, args: parsed.data };
}

The same gate in Python is a Pydantic model. Validate inside a try/except and return the error string instead of raising, so the model gets the reason back:

from pydantic import BaseModel, EmailStr, ValidationError, conint

class SendInvite(BaseModel):
    attendee_email: EmailStr
    starts_at: str                       # ISO 8601, validated downstream
    duration_mins: conint(ge=5, le=240)

def validate_args(raw_args: dict):
    try:
        return {"ok": True, "args": SendInvite.model_validate(raw_args)}
    except ValidationError as e:
        return {"ok": False, "error": "; ".join(err["msg"] for err in e.errors())}

The important move is the return, not the check. A thrown exception kills the run. A structured { ok: false, error } gets handed back to the model, which retries with the reason (see the retry lane in the diagram above).

3. Guard the execution itself

A valid tool call can still cause damage if it runs twice or can't be undone. So make writes idempotent, and put a confirmation gate in front of anything irreversible.

const seen = new Set<string>();

async function guardedExecute(call: ToolCall) {
  // Same key already ran? Return the prior result instead of doing it twice.
  if (seen.has(call.idempotencyKey)) {
    return { ok: true, note: "already done, skipped duplicate" };
  }
  // Irreversible actions (send, charge, delete) need an explicit gate.
  if (call.irreversible && !isConfirmed(call)) {
    return { ok: false, error: "needs confirmation before running" };
  }
  seen.add(call.idempotencyKey);
  return execute(call);
}

The Set here is illustrative. In production the key lives in Redis or your database, so a restart or a second worker still sees it. Agents retry constantly (networks time out and the model tries again), and without a durable idempotency key you send the invite twice. Give each write a stable key, gate the irreversible actions, and scope every tool's credentials to just its job.

4. Verify the result, don't trust it

A tool returning success: true is a claim, not proof. Verify the outcome against the source of truth before the agent acts on it, because tool-call failures compound: one wrong result quietly poisons every step after it.

async function callWithVerify(propose, maxTries = 3) {
  let lastError = "";
  for (let attempt = 0; attempt < maxTries; attempt++) {
    const call = propose(lastError);            // model re-proposes given the last error
    const result = await guardedExecute(call);
    if (!result.ok) { lastError = result.error; continue; }

    // The tool said "done". Prove it against the source of truth.
    const verified = await sourceOfTruthHas(call);
    if (verified) return result;
    lastError = "tool reported success but the change was not found";
  }
  return { ok: false, error: `gave up after ${maxTries} tries: ${lastError}` };
}

For the invite, sourceOfTruthHas reads the calendar API back and checks the event exists. For a git push, it queries the remote. The rule is the same one good engineers already live by: never derive a fact from a self-report when you can read the source. A capped retry loop keeps a confused model from burning your token budget forever.

The takeaway

Reliable tool use comes from four cheap habits, not a bigger model:

Narrow tools so there's little to hallucinate into.
Validated arguments, treated as untrusted input, with the failure reason handed back.
Guarded execution: idempotent writes, a gate on anything irreversible, least-privilege credentials.
Verified results checked against the source of truth, not the tool's own "success."

The model proposes; your code disposes. Wrap those four checkpoints around every tool and the same model that flaked in your demo becomes an agent you can actually leave running.

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: Types Vanish at Runtime (And How to Fix It)

Diven Rastdus — Wed, 22 Jul 2026 10:16:15 +0000

TypeScript's types don't exist at runtime. The compiler deletes every interface and type annotation before your code runs, so const user = data as User is a promise the compiler can't keep. The day the real data doesn't match, production throws an error the type checker swore was impossible.

You trust the green check. tsc passes. Your tests pass. You ship on Friday. Then Monday a Cannot read properties of undefined (reading 'name') lands in your error tracker, on a line the type system called safe. Nothing in your code changed. An API you consume changed one field, and TypeScript never noticed.

Here is the whole article in one picture:

I ship apps that consume data from other people's APIs. Here is the shape of a bug I have watched happen more than once. One response field's type said number. Then a vendor shipped an update and started returning it as a string, sometimes null. My code did the obvious thing: const profile = await res.json() as Profile. Every type looked right in the editor. The build passed. And a screen that read profile.score.toFixed(1) started crashing for a slice of users, because score now arrived as a string and strings have no toFixed. No compiler error. No test failure. Just a runtime explosion at the exact spot TypeScript promised was safe.

That bug isn't special. It's the single most common way TypeScript lets you down, and it has one root cause.

Why your types disappear

TypeScript is a compile-time tool. When you run tsc, it checks your types and then throws them away. Transpilers like esbuild, swc, and Babel skip the check entirely; they just strip the types out. Interfaces, type aliases, and annotations emit zero runtime code. What ships to production is plain JavaScript with no memory that types ever existed.

Watch what happens to a simple file:

// user.ts  (what you wrote)
interface User {
  id: number
  name: string
}

function greet(user: User) {
  return `Hi ${user.name}`
}

// user.js  (what actually runs)
function greet(user) {
  return `Hi ${user.name}`;
}

The interface User is gone. Not minified, not hidden. Gone. At runtime there is no User, no id: number check, nothing that inspects the shape of user. (Enums and classes are the exception; they emit real JavaScript. Interfaces and type aliases never do.)

So a type annotation is a note to the compiler, not a guard on your data. That distinction is where production breaks.

The lie hides at the boundary

Inside code you fully control, TypeScript is excellent. It tracks types across functions and catches real mistakes. The danger starts where data crosses into your program from a place the compiler cannot see.

Every one of these hands you any or an unchecked value:

const data = await res.json()               // any
const parsed = JSON.parse(str)              // any
const saved = localStorage.getItem('user') // string | null
const key = process.env.API_KEY            // string | undefined

any is the real problem. It's the one type that turns the checker off. Assign any to a typed variable and TypeScript stops complaining, because any is assignable to everything:

interface Profile {
  score: number
}

const profile: Profile = await res.json()  // no error, ever
console.log(profile.score.toFixed(1))      // crashes if score is a string

The cast version is worse, because it looks deliberate and careful:

const profile = (await res.json()) as Profile

as isn't a conversion. It doesn't check anything. It's you telling the compiler "trust me, this is a Profile," and the compiler obeying without looking. If you're wrong, nobody finds out until a user hits the broken screen.

The fix: parse, don't cast

Don't tell the compiler what the data is. Prove it at runtime, at the moment it enters. Use a schema validator (Zod, Valibot, and ArkType all do this). Derive your static type from that schema, so you have one source of truth instead of two that drift apart.

import { z } from 'zod'

const Profile = z.object({
  id: z.number(),
  name: z.string(),
  score: z.number(),
})

type Profile = z.infer<typeof Profile>   // the static type, generated from the schema

const profile = Profile.parse(await res.json())
// profile is now a real Profile, checked field by field
console.log(profile.score.toFixed(1))    // safe

If the API returns score as a string, .parse() throws immediately, at the boundary, with a precise message naming the field that was wrong. The bug surfaces where it enters, not three screens later in code that looks innocent.

When you don't want to throw, use safeParse and handle the failure like any other bad input:

const result = Profile.safeParse(await res.json())
if (!result.success) {
  logBadResponse(result.error)   // you decide: retry, default, alert
  return
}
const profile = result.data      // typed and trusted

The rule is three words: parse, don't cast. A cast asserts. A parse verifies. Only one of them survives contact with real data.

Harden the rest of your boundaries

The API response is the obvious hole. The same class of bug hides in quieter places.

localStorage returns whatever a past release wrote, which may not match this release's shape:

const raw = localStorage.getItem('settings')
// Settings is a Zod schema you defined, same idea as Profile above
const settings = Settings.parse(JSON.parse(raw ?? '{}'))

Environment variables are strings or undefined, never the numbers and booleans you treat them as. Validate them once, at startup, so a missing key fails on boot instead of at 3am:

const Env = z.object({
  PORT: z.coerce.number(),
  API_KEY: z.string().min(1),
})
const env = Env.parse(process.env)   // crashes on boot if misconfigured

Two tsconfig flags close the remaining gaps. strict turns on the checks that matter. noUncheckedIndexedAccess stops TypeScript from lying about array and record access:

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true
  }
}

Without that second flag, arr[10] is typed as your element type even when the array holds three items. With it, the type becomes T | undefined and the compiler makes you handle the empty case. One line of config kills a whole family of "undefined is not a function" crashes.

One last habit: prefer unknown over any at every edge. unknown also accepts anything, but it refuses to let you touch the value until you narrow it, so the compiler pushes you toward validating instead of assuming.

The takeaway

TypeScript guarantees consistency inside the boundary it can see. It guarantees nothing about data crossing into that boundary from an API, a file, storage, or a user. Your types are a compile-time contract, and the compiler tears the contract up before your code runs.

So draw the line yourself. Validate at every edge with a schema, generate your types from that schema, and trust your types everywhere inside. Parse, don't cast. Do that, and the green check finally means what you always assumed it meant.

What's the worst runtime type bug that walked straight past tsc for you? Mine is the one up top: a vendor quietly flipping a number field to a string. Tell me yours in the comments.

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.

Next.js in 2026: The 5 Features That Change How You Ship (And 2 Still Missing)

Diven Rastdus — Mon, 20 Jul 2026 10:13:10 +0000

Next.js 16 didn't add a pile of new APIs. It changed the defaults you never think about: how your app builds, whether a page is cached, and which file intercepts a request. If you're upgrading from 15, five of those changes show up in your day, and two things I wanted still aren't here.

I run Next.js 16 in production on a small app (16.2 with Neon and Clerk), so this is the upgrade as it actually lands, not the changelog.

1. Turbopack is the default bundler

Turbopack is stable now and the default for every new project. You get 2 to 5x faster production builds and up to 10x faster Fast Refresh, with no config change. That's the single most noticeable difference on day one. On my own app (16.2), a clean production build lands in about 19 seconds, 8.3 of them Turbopack compiling, and I never touched the bundler config.

If you've got a custom webpack setup that Turbopack can't handle yet, opt out per command:

next dev --webpack
next build --webpack

Turbopack also caches compiler artifacts to disk between runs. For next dev that filesystem cache is on by default since 16.1, so your second dev start is faster for free. The same cache for next build is still experimental, and you opt in (more on that below):

// next.config.ts
const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForBuild: true, // experimental
  },
};

export default nextConfig;

2. Caching is opt-in now with "use cache"

This is the biggest mental shift, and the one that breaks the most assumptions. In Next.js 16, every page, layout, and route handler runs at request time by default. Nothing's silently cached. You opt a page or component into the cache with the "use cache" directive, and the compiler generates the cache key for you.

Turn it on in config first:

// next.config.ts
const nextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Then mark what you actually want cached:

// app/products/page.tsx
export default async function ProductsPage() {
  'use cache';
  const products = await db.products.findMany();
  return <ProductGrid products={products} />;
}

The old implicit caching is gone. So are the experimental.ppr and experimental.dynamicIO flags, which the new Cache Components model replaces. If you upgrade a 15 app and your data suddenly looks fresher (and your database busier), that's why. Pages that used to be static now hit the database on every request, until you add "use cache" back where you meant it.

3. middleware.ts is proxy.ts now

This is the one that caught me on upgrade. middleware.ts is deprecated in favor of proxy.ts. The rename itself is mechanical, and a codemod does it for you:

npx @next/codemod@canary middleware-to-proxy

It renames the file and the exported function:

// proxy.ts (was middleware.ts)
import { NextRequest, NextResponse } from 'next/server';

export default function proxy(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url));
}

The part that isn't mechanical is the runtime. proxy.ts runs on the Node.js runtime, and it's meant to stay a thin proxy that clarifies your network boundary. If your old middleware leaned on Edge-runtime behavior, that's the bit to check, not the rename. My Clerk auth check moved over fine once I renamed the file and the function, but I would not have found that out from the changelog. middleware.ts still works for Edge cases, but it's deprecated and gets removed later.

4. New cache invalidation: updateTag() and refresh()

Once caching is explicit, invalidation has to be too. Next.js 16 splits it into three intents, and picking the wrong one is how you ship a stale UI. Here's the decision I make every time:

updateTag() is new and Server-Actions-only. It expires the cache and reads fresh data in the same request, so the user sees their own write immediately:

'use server';
import { updateTag } from 'next/cache';

export async function saveProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile);
  updateTag(`user-${userId}`); // read-your-writes
}

revalidateTag() now requires a cache profile as its second argument, which enables stale-while-revalidate. The single-argument form is deprecated:

revalidateTag('blog-posts', 'max'); // serve cached now, revalidate in background

And refresh() re-fetches uncached data shown elsewhere on the page (a notification count, a live metric) without touching the cache at all. Three intents, three functions, no guessing.

5. The React Compiler is stable

Built-in React Compiler support is stable now, following the compiler's 1.0 release. It automatically memoizes components and cuts unnecessary re-renders with zero code changes. It's not on by default, because it relies on Babel and can slow your build, so you enable it deliberately:

// next.config.ts
const nextConfig = {
  reactCompiler: true,
};

export default nextConfig;

You also inherit React 19.2 in the App Router: View Transitions for animating navigations, useEffectEvent for non-reactive Effect logic, and <Activity> for keeping background UI mounted with its state intact.

The 2 I'm still waiting for

Filesystem build caching that's stable, not experimental. The dev filesystem cache is on by default now, and it's genuinely good. The build cache (turbopackFileSystemCacheForBuild) is still experimental, and that's the one I want most. A cold CI runner rebuilding from scratch on every push is exactly where a persistent compiler cache pays off. It's also exactly where I don't want to lean on an experimental flag yet.

One caching mental model instead of four functions. Cache Components is the right direction. But shipping it means holding "use cache", updateTag(), revalidateTag(tag, profile), and refresh() in your head at once, plus a cacheLife profile system on top. It's powerful. It's also a lot of surface area for "cache this and invalidate it correctly." I want the diagram above to eventually be one function.

The takeaway

If you upgrade one 15 app to 16 this week, budget for exactly two things. Rename middleware.ts to proxy.ts (and check the runtime, not just the filename), then go find every place that relied on implicit caching and add "use cache" back. Turbopack, the React Compiler, and the new invalidation APIs are upside you mostly get for free. The dynamic-by-default flip is the one that'll surprise you in production if you skip it. Run the codemod, read your build logs, and cache on purpose.

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.

React Native vs Flutter in 2026: When Each One Actually Wins

Diven Rastdus — Mon, 13 Jul 2026 10:19:17 +0000

React Native and Flutter are both production-ready in 2026, so the honest answer to "which one should I use" isn't "the faster one." It comes down to two things: your team and your UI. If your people already write JavaScript and React, React Native wins. If your product is a custom-drawn interface that has to look identical on every screen, Flutter wins. I ship four apps on Google Play, all React Native, and even I'll tell you the speed benchmark is the wrong reason to pick either one.

That's the whole game, and most "X vs Y" posts miss it. I don't reach for React Native because it beats Flutter on a chart. I reach for it because my team already thinks in React. So let me draw the actual boundary, starting with the stale objections that both frameworks already killed.

Did the old criticisms even survive to 2026?

Mostly no, and that's the first thing to fix. Half the comparison posts online still argue about problems both frameworks already solved.

React Native's slow "bridge" is gone. The New Architecture (Fabric plus TurboModules, talking to native code directly through JSI) has been the default since React Native 0.76 and mandatory since 0.82. The old bridge has since been removed entirely. The current release is 0.86, shipped in June 2026. So don't call React Native "bridge-based" anymore. It stopped being true a while ago.

Flutter's old shader jank is gone too. The Impeller renderer precompiles shaders at build time, which killed the first-run animation stutter. It's been the default on iOS for years and became the default on Android (API 29 and up) in the 3.27 release. The current stable is Flutter 3.44 on Dart 3.12. Both frameworks grew up. Compare the 2026 versions, not the 2021 ones.

When does React Native actually win?

React Native wins when your team and your codebase already speak JavaScript. That single fact decides more projects than any benchmark.

Here's why it compounds. Your developers reuse the React mental model they already have: components, hooks, JSX. You share validation, types, and business logic with a React web app. You pull from npm, the largest package registry in software. And with Expo you ship JavaScript-only fixes over the air, skipping the app-store review queue.

# React Native + Expo: push a JS-only fix, no store review
eas update --branch production --message "hotfix: null guard on profile"

The component itself is just React:

// React Native: a counter, in JSX + hooks
import { useState } from "react";
import { Text, Pressable } from "react-native";

export function Counter() {
  const [count, setCount] = useState(0);
  return (
    <Pressable onPress={() => setCount(count + 1)}>
      <Text>Tapped {count} times</Text>
    </Pressable>
  );
}

If that code looks familiar, React Native is your shortcut. You hire from the huge pool of web developers, and they're productive on day one. You'll also find React Native inside big production apps like Shopify and Microsoft.

When does Flutter actually win?

Flutter wins when the UI is the product. If you're drawing a custom design language and every pixel matters, Flutter was built for exactly that.

Flutter doesn't use the platform's native widgets. It paints every pixel itself with Impeller, so a screen looks identical on an old Android phone and a new iPhone. That control shines in animation-heavy, brand-heavy interfaces aiming for 120fps. You also ship one compiled binary. Dart builds ahead of time to native machine code, with no JavaScript runtime living inside your app.

// Flutter: the same counter, in Dart widgets
class Counter extends StatefulWidget {
  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int count = 0;
  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => setState(() => count++),
      child: Text('Tapped $count times'),
    );
  }
}

# Flutter: one compiled binary, ahead-of-time, no JS runtime
flutter build appbundle --release

The shape is different. Flutter has its own widget and state model, and you write it in Dart. If your team has no web background to reuse, that's not a cost. It's a clean slate. Flutter also reaches further out of the box: the same codebase runs on mobile, desktop, and embedded devices. Google Pay and Nubank are built this way.

So which one is faster?

For the app most teams actually build, you won't feel a difference in 2026. Lists, forms, navigation, and network calls run smoothly on both.

Flutter keeps an edge when graphics get heavy. Compiled Dart plus Impeller handles dense animation and custom rendering with less effort. React Native's New Architecture closed the old gap for normal app work, because native calls are now synchronous and Hermes runs the JavaScript fast. So pick on developer experience, not on a micro-benchmark, unless you're building something game-like or visually intense.

Is either one dying in 2026?

No, and this matters if you're betting a product on your choice. Both frameworks got fresh institutional backing in the last year.

Meta moved React and React Native under a new React Foundation in late 2025, with a governing board that includes Amazon, Microsoft, and Vercel. Google kept shipping Flutter on its steady roughly-quarterly cadence, and handed desktop stewardship to Canonical so its own team can focus on mobile and AI tooling. Neither project is coasting. You're choosing between two well-funded, actively maintained frameworks.

The real tie-breaker

Two questions settle it. Does your team already write React and JavaScript? And is your UI a standard native feel or a fully custom design language?

Cross those answers. A React team plus a standard UI points hard at React Native. No web background plus a bespoke, animated design points hard at Flutter. Everything else is a close call where either one ships a great app. So pick the framework your team can move fastest in. For most teams shipping a standard app, that's the stack they already know, and that alone is a legitimate reason to choose it. Both are safe bets in 2026. The only real mistake is choosing on a benchmark you'll never actually feel.

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 AI Agents Gotcha That Breaks Production (And How to Fix It)

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

Here is the gotcha: an AI agent's process state is not the world state. An agent run ends one of two ways you can see: a success report, or a crash. Neither tells you whether its side effects actually happened. Production breaks in the gap: you retry a dead agent that already acted and fire the action twice, or you trust a success report for an action that never ran.

I run autonomous agents in production every day. This one gotcha has bitten me from both sides in the same week. One killed worker nearly re-submitted the same listing to a directory that reviews duplicates by hand.

Here is how the near-duplicate happened. A billing limit killed one of my browser automation workers mid-run. It died with 84 bytes of stdout. I read that as total failure and started redoing its jobs from the top. An hour later I found the truth in its leftover browser tabs. The worker had already completed one directory submission (the listing was live), and had a second one half-filled in an open form. My "redo everything" pass was minutes away from submitting the live listing a second time.

That is the whole trap in one story. Now let's generalize it, because your stack has the same bug.

Why do retries double-fire side effects?

A dead process is not undone work. When a worker dies, you lose the report. Every external action it completed stays completed.

Most agent pipelines start with retry logic like this:

result = run_agent(publish_task)
if not result.ok:
    # If the first run already published before it died,
    # this line publishes it twice.
    result = run_agent(publish_task)

This is perfectly safe for a pure function. It is a bug for anything that does a POST, submits a form, sends an email, or moves money. The retry silently assumes the failed run changed nothing. Look at the quadrant diagram above: that assumption only holds in one of the two "agent died" states, and you cannot tell them apart from the exit code.

LLM agents make this worse than ordinary jobs, for two reasons. Their tasks are long, so death lands mid-sequence with three of seven actions done. And their actions live on other people's platforms, where a duplicate submission, comment, or charge is visible, embarrassing, and sometimes unrecoverable.

Why can't you trust an agent's success report?

An agent's "done" is generated text, not a receipt.

My publishing agent once reported a clean cross-post to a second platform. The API token was missing from its environment at runtime, so the publish had silently failed. The agent still summarized the task as complete. Our outcomes poller caught the lie a day later by querying the platform and finding nothing.

Another time, a read-only monitoring agent reported that a human had clicked a confirmation button. It had no way to observe a click. It inferred the click from a misread screenshot and stated the inference as fact. That false "resolved" sat in a status file, hiding a deadline that mattered.

Neither agent was broken. This is just what language models do: they produce the most plausible completion of "report on your task." A plausible report and a true report look identical from inside the transcript. The only way to tell them apart is to look outside the transcript.

How do you fix it?

Treat every agent task like an unreliable network call with side effects. That gives you three concrete rules: verify against the source of truth, put an idempotency key on every external action, and reconcile before any retry.

Rule 1: verify "done" against the platform, never against the report.

USERNAME = "astraedus"  # your Dev.to username

def actually_published(slug: str) -> bool:
    r = requests.get(f"https://dev.to/api/articles/{USERNAME}/{slug}")
    return r.status_code == 200

report = run_agent(publish_task)
state = "published" if actually_published(slug) else "unverified"

The agent's report never touches your state store. Only the platform's answer does. When you cannot verify, record unverified, not done. An honest unknown beats a confident fiction.

Rule 2: give every external action an idempotency key.

The ledger below is any durable key-value store. A dict works for a demo; use SQLite or Redis in production.

import hashlib, shelve

ledger = shelve.open("side_effects.db")

key = hashlib.sha256(f"submit:{directory}:{app_slug}".encode()).hexdigest()

if key in ledger:
    # This action already fired once. Return the recorded
    # outcome instead of re-running the side effect.
    result = ledger[key]
else:
    outcome = run_agent(submit_task)
    ledger[key] = verify(outcome)

Payment APIs like Stripe support idempotency keys exactly so a retried request cannot charge a card twice. Your agent pipeline needs the same discipline for the same reason. The key comes from what the action does, not from which run attempts it. A second run computes the same key, finds it in the ledger, and gets the stored outcome back. The side effect never fires twice.

Rule 3: when a run dies, reconcile before you retry.

Before re-dispatching anything, inventory what the dead worker left behind: files it wrote, the git status of any repo it touched, its open browser tabs or sessions, and the live URLs it may have created. Each artifact tells you which actions completed. The recovery loop is small:

def reconcile_then_retry(task):
    evidence = inventory(task)  # files, git status, live URLs, open sessions
    for action in task.actions:
        if action.key in ledger:
            continue                          # fired and recorded: skip
        if action.visible_in(evidence):
            ledger[action.key] = "verified"   # fired, never recorded: record
        else:
            dispatch(action)                  # genuinely missing: safe to run

In my directory incident, a 30-second tab inventory would have shown me the live listing and saved the near-duplicate.

What should you do differently tomorrow?

Add a side_effects table and make every retry path call reconcile first. The one detail that matters most: assign the idempotency key before the agent runs, not after it fails. A key created during recovery cannot protect the run that just died.

None of this needs a framework. A hash function, a key-value table, and the platform's read API cover all three rules. What it needs is the mental shift: your agent does not tell you what happened. The world does.

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.

Mood Trackers Without a Subscription (Free, No Paywall)

Diven Rastdus — Thu, 09 Jul 2026 22:43:40 +0000

There's a special kind of irony in paying a monthly fee to write down how you feel. You install a mood tracker to understand your own head, and three taps later there's a screen offering you "Premium" for a recurring charge, with your fuller stats and half the features waiting behind it. The thing you built to look after yourself now has a subscription attached, right next to your streaming, your storage, and everything else quietly draining the account.

Mood tracking does not need to cost anything, and it definitely doesn't need to be recurring. A mood log is text and numbers in a small local database. The compute is trivial. So when an app charges monthly, you're not paying for the tracking, you're paying for a business model. This is a straight look at which popular trackers put a subscription in your way, what they actually charge, and the genuinely free, no-paywall options, including the app I built, the SoulSync mood tracker.

Prices below were checked at the time of writing. App pricing changes and varies by region, so treat any number as "confirm it on the store," and where a current price couldn't be pinned down cleanly I've said so instead of guessing.

How mood tracking turned into a subscription

Freemium works like this. The app is free to install and free to start, which gets it onto your phone and into your routine. Then the features that make it feel finished, the deeper stats, the extra moods, the correlations, the themes, sit behind a recurring payment. By the time you hit the wall, you've already got weeks of history in the app and you're the least likely to walk away. That's the design, and it's a good business. It's just not in your interest.

The tell is that the paywalled features are almost never expensive to provide. Showing you a chart of your own data doesn't cost the company anything per month. The subscription isn't priced to the cost of serving you. It's priced to what a captured user will pay. Recognising that makes it much easier to walk past the upgrade screen.

Who charges a subscription (and roughly what)

Here's how the pricing actually breaks down. Some of these apps have usable free tiers, so "has a subscription" doesn't automatically mean "unusable without paying." I've noted that where it applies.

App	Free tier usable?	Paid tier	Account required?
SoulSync mood tracker	Fully, everything	None	No
Daylio	Yes, core features	Premium (paid upgrade)	No (free tier)
Pixels (Year in Pixels)	Yes	Pixels+ paid upgrade; cloud sync paid	No (optional for sync)
Finch	Yes, fully functional	Finch Plus subscription	No (optional for backup)
Bearable	Yes, most features	Subscription	Yes, to use at all
MindDoc (formerly Moodpath)	Limited	Subscription	Yes

A few specifics, with the caveats attached:

Bearable charges roughly $6.99 a month or $34.99 a year at the time of writing, and it requires you to create an account before you can use it at all. To its credit, most of its features are usable free; the subscription adds the deeper analytics and correlation reports.
Finch keeps its free tier functional, and Finch Plus is a subscription in the region of $10 a month or around $70 a year, though the exact figure varies by region so check your store. Plus mostly adds extra customization rather than core tracking, which is a fairer split than most.
Pixels (Year in Pixels) is free to use, with a paid Pixels+ upgrade for extra features and cloud sync. The core year-in-pixels grid is free and works without an account.
Daylio is freemium with a paid Premium tier. Its exact current price is inconsistent enough across sources that I won't print a number I can't stand behind, so check the store. Worth saying: Daylio's free tier is usable and doesn't require an account.
MindDoc, previously Moodpath, requires an account and leans clinical, with a paid subscription for the fuller experience. Again the pricing is messy across listings, so verify it live.

The pattern across the table: the apps that insist on an account before you can start (Bearable, MindDoc) are also the ones built around a subscription and the cloud. The ones that stay closest to free (Daylio, Pixels, Finch's core) also stay closest to on-device and no-login. That's not a coincidence. Subscriptions and servers travel together.

The genuinely free, no-subscription options

If you want to skip the paywall entirely, there are two kinds of app that never bring one out.

SoulSync is the app I built, and it has no paid tier at all. Not "free with an upgrade," just free. The 10-point mood scale, activity and photo entries, the stats screen with trends and day-of-week patterns and activity correlation, the Insights tab, five themes, and JSON export are all in the one free app. It's open source under GPL-3.0 and stores everything locally with no account, so there's no server to justify a monthly charge and no captured data to monetise later. The absence of a subscription isn't a promotion that expires. It's structural.

Open-source trackers on F-Droid are the other reliably free category, because they're community projects rather than businesses. Track & Graph, Daily You, Mood Cairns, and moreDays are all free, all GPL-3.0, and none of them will ever show you an upgrade screen. They differ in focus (Track & Graph is configurable, Daily You and moreDays lean journaling, Mood Cairns is offline mood-only), and I've compared them in the best open-source mood trackers for 2026.

And to be fair to the freemium apps: if you don't need the paywalled parts, Daylio, Pixels, and Finch all have free tiers you can use indefinitely without paying. "Has a subscription" and "can't be used for free" aren't the same thing. The reason to prefer a genuinely subscription-free app is that you never hit the wall at all, and you're never one policy change away from your existing features moving behind it.

What you're not giving up by going free

People assume the free option must be the worse one. For mood tracking, that assumption mostly doesn't hold, because the expensive-to-build part isn't the tracking. A free, local, open-source tracker can give you the finer mood scale, the correlations, and the full stats, since none of that costs anything to run. What a subscription actually pays for is cross-device cloud sync and a company's ongoing salary. If you don't need the sync, you're paying for the salary.

The one real tradeoff is the same as with any no-account app: you run your own backup with an export instead of leaning on a synced server. That's a fair price for never paying a monthly fee, and it's covered in more depth in our piece on no-account, private mood tracking.

FAQ

Is there a completely free mood tracker with no subscription?

Yes. SoulSync has no paid tier at all, and the open-source trackers on F-Droid (Track & Graph, Daily You, Mood Cairns, moreDays) are free by design. None of them will ever show you an upgrade screen, because they aren't built to sell one.

Do I have to pay for Daylio?

No, its free tier is usable and doesn't require an account. You only pay if you want Premium features. If what you want is on the paid side, a free, open-source Daylio alternative keeps every feature free.

Why do mood trackers charge a subscription at all?

Because freemium is a strong business model, not because tracking is expensive. Logging text and numbers to a local database costs almost nothing. The subscription is priced to what a committed user will pay, not to the cost of serving them, which is exactly why you can safely skip it.

Is a free mood tracker worse than a paid one?

Usually not, for the core job. The finer scale, the stats, and the correlations are cheap to build, so a good free app includes them. Subscriptions mostly buy cloud sync and fund the company. If you don't need sync across devices, free gives up very little.

Which free tracker is the most private?

The strongest combination is free, no account, on-device, and open source, so the privacy is verifiable. SoulSync fits that, as do the F-Droid apps above. A closed app's free tier can still be private, but you're trusting the policy rather than checking the code.

You should not pay a monthly fee to keep a record of your own moods. If you want a tracker with every feature free, no account, and no paywall to ever hit, SoulSync is free on Google Play and open source on GitHub. Log your first entry in under a minute, and there's no upgrade screen waiting behind it.

DEV Community: Diven Rastdus

5 AI Agent Features That Define 2026 (And 2 I'm Still Waiting For)

1. MCP became the universal tool layer

2. Prompt caching made the agent loop affordable

3. Computer use turned agents into hands, not just mouths

4. Background subagents made parallelism the default

5. A2A let agents talk to other agents

The 2 I'm still waiting for

The takeaway

5 TypeScript Features That Define 2026 (And 2 I'm Still Waiting For)

1. The compiler went native, and it's roughly 10x faster

2. You can run TypeScript with no build step

3. import defer lets you lazy-load a module

4. --module node20 gives you a target that stops moving

5. Better defaults and hovers make the editor pull its weight

The 2 I'm still waiting for

Takeaway

How to Give Your React Native App a Memory That Actually Works

Your app has three kinds of memory

Match each value to the right tier

Why your data disappears: AsyncStorage is async

Make key-value memory synchronous with MMKV

Gate the first render on hydration

The takeaway

I Built a Practice App Because Every "Duolingo for Music" Kept Failing Me

The gap I kept hitting

A real DAG, not a leveled list

Applying the research instead of guessing

The stack

Storage: local-first, cloud optional

What's next

TypeScript vs JavaScript: Which Should You Use in 2026

They are not two competing languages

The two arguments against TypeScript died in 2026

When plain JavaScript still wins

When TypeScript wins (which is most of the time)

The 2026 decision, in one view

Two gotchas before you jump

The takeaway

The 5 Things That Silently Break AI Agents in Production

1. The agent forgets everything between steps

2. It trusts its own "done"

3. A tool call "succeeds" but did nothing

4. Small errors compound into a broken chain

5. The loop never stops (and neither does the bill)

The pattern under all five

How to Give Your AI Agent Tool Use That Actually Works

The failure nobody catches in the demo

1. Design tools the model can't misuse

2. Validate arguments before you execute

3. Guard the execution itself

4. Verify the result, don't trust it

The takeaway

The TypeScript Gotcha That Silently Breaks Production: Types Vanish at Runtime (And How to Fix It)

Why your types disappear

The lie hides at the boundary

The fix: parse, don't cast

Harden the rest of your boundaries

The takeaway

Next.js in 2026: The 5 Features That Change How You Ship (And 2 Still Missing)

1. Turbopack is the default bundler

2. Caching is opt-in now with "use cache"

3. middleware.ts is proxy.ts now

4. New cache invalidation: updateTag() and refresh()

5. The React Compiler is stable

The 2 I'm still waiting for

The takeaway

React Native vs Flutter in 2026: When Each One Actually Wins

Did the old criticisms even survive to 2026?

When does React Native actually win?

When does Flutter actually win?

So which one is faster?

Is either one dying in 2026?

The real tie-breaker

The AI Agents Gotcha That Breaks Production (And How to Fix It)

Why do retries double-fire side effects?

Why can't you trust an agent's success report?

How do you fix it?

What should you do differently tomorrow?

Mood Trackers Without a Subscription (Free, No Paywall)

3. `import defer` lets you lazy-load a module

4. `--module node20` gives you a target that stops moving