It started as about twenty lines. By the end of the day it could think in steps and check its own work, and most of what I actually learned came from things going wrong on the way there.

The first call failed twice, neither time because of the code

The first version was the same snippet everyone starts with:

const response = await openai.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [
    { role: "system", content: "You are a helpful assistant." },
    { role: "user", content: "Hello! Can you help me with a coding problem?" },
  ],
});
console.log(response.choices[0].message.content);

First error: ERR_MODULE_NOT_FOUND. My package.json had tiktoken in it and nothing else, so npm install openai fixed that. Second error:

RateLimitError: 429 You have no credits remaining.

The name is misleading, because I wasn't sending too many requests. There was simply no money on the API account, and a ChatGPT subscription doesn't pay for API calls. It did tell me one useful thing though: the key was fine, since a bad key gets you a 401.

Rather than top up straight away, I tried NVIDIA's hosted models and then OpenRouter, and that turned out to be the first real lesson. I didn't have to rewrite anything. Both speak the same API format, so moving was two lines:

const openai = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
});

To check there was no magic in the SDK, I also replaced it with plain fetch for a while, and got the same answer back. Under the wrapper it's a POST request with some JSON in it. That JSON is the whole interface: a model name and a list of messages.

What the model actually reads

The model doesn't read words. Before it sees anything, your text is split into tokens, and each token is a number. That's what tiktoken was doing in my package.json, so I ran it on my own prompt:

import { encoding_for_model } from "tiktoken";

const enc = encoding_for_model("gpt-4o-mini");
console.log(enc.encode("Hello! Can you help me with a coding problem?"));

Eleven tokens came back:

13225, 0, 4101, 481, 1652, 668, 483, 261, 22458, 4792, 30
Hello  !   Can you help me with a  coding problem ?

Common words get a token each, and notice the spaces belong to the token that follows them. A word the tokenizer hasn't seen much gets broken up instead, so the name of this blog comes out as ho and isted.

From there, generating text is one small operation on repeat. The model looks at all the tokens so far, works out how likely each possible next token is, picks one, adds it to the end, and goes again. A long answer is that loop running a few hundred times. Nobody planned the sentence in advance, and it's why streaming responses arrive a few pieces at a time.

It's also why APIs bill per token rather than per request. A token is the unit of work, and it counts in both directions.

The model remembers nothing

This was the one that changed how I think about all of it. I'd assumed that chat means the model is keeping track of the conversation. It isn't. Each API call starts from nothing.

The way a chat works is that your code keeps the list and resends all of it, every time:

const messages = [
  { role: "system", content: SYSTEM_PROMPT },
  { role: "user", content: question },
];

// after each reply
messages.push({ role: "assistant", content: reply });

The memory lives in my array, not in the model. Once I'd seen that, a few things I'd only half understood made sense. Long chats cost more, because every old message gets paid for again on every call. Context windows matter, because that list has a size limit. And an assistant that "forgets" something early in a long chat has usually just had it trimmed off the list by whatever app it's running in.

A system prompt is only the first message

The system prompt sounds like configuration. In practice it's text at the top of that same list, written to steer whatever comes next. I changed mine to one line:

You are a JS expert and only answer questions about JavaScript.

That one line made it refuse things. I asked for the capital of France and got:

I'm here to answer questions specifically about JavaScript.

No code of mine did that. The behaviour came entirely from text that sits in front of the question.

Making it think in steps

If the model only ever predicts the next token, you can shape its answer by making it produce the reasoning first. By the time it writes the final answer, those steps are in the context and it's building on them. This is called chain of thought, and it's just a prompting pattern. So my system prompt grew some rules:

Work through every question in steps, and reply with exactly one step each time.
- START: say in your own words what the user is asking.
- THINK: work out one small part of the answer. Use 2 to 4 THINK steps.
- EVALUATE: check the THINK step before it. Is it correct and complete?
- OUTPUT: give the final answer to the user. This is always the last step.

Always reply with JSON in this format:
{ "step": "START" | "THINK" | "EVALUATE" | "OUTPUT", "content": "..." }

I also added a worked example to the prompt, because showing the format is far more reliable than describing it. My example has a deliberately wrong THINK that the EVALUATE catches, so the model can see what a correction looks like.

Then the code became a loop. Each pass is one API call that returns one step, gets pushed onto the list, and goes back in, until the model says OUTPUT:

for (let i = 0; i < MAX_STEPS; i++) {
  const response = await openai.chat.completions.create({
    model: "openai/gpt-4o-mini",
    response_format: { type: "json_object" },
    messages,
  });

  const reply = response.choices[0].message.content;
  messages.push({ role: "assistant", content: reply });

  const { step, content } = JSON.parse(reply);
  console.log(`[${step}] ${content}`);

  if (step === "OUTPUT") return;
}

Here's a real run, a bit shortened, on [] + {}:

[START] The user wants to know the result of adding an empty array and an empty object.
[THINK] Using the + operator with two objects can lead to type coercion.
[EVALUATE] This is a correct consideration.
[THINK] [] is converted to an empty string, and {} to '[object Object]'.
[EVALUATE] This is correct.
[THINK] [] + {} will result in '' + '[object Object]'.
[EVALUATE] That is correct.
[OUTPUT] [] + {} results in '[object Object]'.

The answer is right, and watching it arrive one step at a time was the most fun part of the day.

What the steps don't do

It would be easy to stop there and call that an agent that checks its own work, but the runs didn't really support that.

I tried a few more JavaScript questions to see how EVALUATE held up. On typeof NaN it did push back on one of its own steps, which was nice to see, and that answer came out right. Then I asked about the old [1, 2, 3].map(parseInt) trap:

[EVALUATE] The evaluations of parseInt with their respective radices are correct.
           The results would lead to NaN for the first two and 3 for the last.
[OUTPUT] [1, 2, 3].map(parseInt) returns [NaN, NaN, 3].

Node says [1, NaN, NaN]. The reasoning looked careful, every step got approved, and the answer was wrong. That's the same model marking its own homework, and the extra steps made a wrong answer look more trustworthy, not less. Running the code would have settled it in a second, so a real check probably needs to be something outside the model, or at least a different one.

The rules weren't followed all the time either. The prompt says to use 2 to 4 THINK steps, and on the France question it went straight from START to OUTPUT. A good refusal, but not what I'd specified. A system prompt is a strong suggestion, and anything that has to hold every time belongs in code. That's why MAX_STEPS is a plain JavaScript constant and not a line in the prompt.

And it costs more. That [] + {} run took eight API calls, each one resending a longer list than the last, for a question a single call would have answered.

So what I actually have is a small file and a better mental model. Text goes in as numbers, the next token gets predicted over and over, and everything that feels like memory or personality is text being put in front of that loop. I still need to learn how the models are trained, which is a much bigger subject, but I can now look at an AI product and guess what's in its messages array.

First published on my blog. Cover photo: McKay Savage, CC BY 2.0, via Wikimedia Commons (source).

The issue was short and had a proper repro, which is always a good sign. The <Markdown> component takes a string of markdown and turns it into HTML for an email. Give it a code block with HTML inside:

```html
<b>bold</b> & <i>x</i>
```

Inline: `<br>`

and you'd expect to see those tags as text, because showing the snippet is the whole point of a code block. What actually came out was this (inline styles stripped):

<pre><code><b>bold</b> & <i>x</i>
</code></pre>
<p>Inline: <code><br></code></p>

The tags went into the email as real tags. So a tutorial explaining <b> shows you bold text, and the <br> in that sentence is just a line break. Nothing crashes and nothing logs an error. The code sample quietly goes missing.

Why it happened

react-email uses marked to parse the markdown, and marked's own renderer does escape code. This is the relevant line from the code method in its current source:

(escaped ? code : escapeHtmlEntities(code, true))

The catch is that email needs inline styles, so react-email replaces marked's renderers with its own, one per element, each adding a style attribute. Its code and codespan renderers looked like this, shortened:

renderer.code = ({ text }) => {
  text = `${text.replace(/\n$/, '')}\n`;
  return `<pre style="..."><code>${text}</code></pre>\n`;
};

Overriding a renderer replaces all of it, including the part you weren't thinking about. The styling came across and the escaping didn't. It's an easy thing to miss, since every example you test with during development is probably plain code with no angle brackets in it.

The fix

marked doesn't export its escape helper, so I added a small one next to the existing markdown utils, escaping the same five characters:

const htmlEscapes: Record<string, string> = {
  '&': '&amp;',
  '<': '&lt;',
  '>': '&gt;',
  '"': '&quot;',
  "'": '&#39;',
};

export const escapeHtml = (text: string) =>
  text.replace(/[&<>"']/g, (char) => htmlEscapes[char] ?? char);

It's one regex with a lookup rather than a chain of .replace() calls, which also means & doesn't need to go first. In a chain, escaping < and then & would turn < into <.

Then the two renderers use it:

renderer.code = ({ text, escaped }) => {
  // ...
  return `...<code>${escaped ? text : escapeHtml(text)}</code></pre>\n`;
};

renderer.codespan = ({ text }) => {
  return `...>${escapeHtml(text)}</code>`;
};

That escaped flag is the bit I nearly didn't think about. A marked extension, such as a syntax highlighter, can escape the code itself and set the flag on the token. Escaping everything regardless would escape that output a second time, and readers would see a literal < in their code sample. So I kept the same check marked uses.

The test puts HTML in both a fenced block and inline code, then checks both sides: the escaped text has to be there, and the raw tags have to be gone.

expect(actualOutput).toContain('&lt;br&gt;</code>');
expect(actualOutput).not.toContain('<br>');

It fails on canary and passes with the change.

What this doesn't do

It's tempting to call this a security fix, and it isn't one. It only covers code. marked passes raw HTML in the rest of the markdown straight through, and I didn't change that, so this still ends up in your email as a real tag:

Some text with <b>real HTML</b> in it.

That's normal for markdown, but it means <Markdown> isn't a sanitiser. If the string comes from your users, you still need to clean it before it gets there.

I also left the existing TODO: Support all options alone, so the code block still ignores its language. It would have been easy to tidy that up in the same PR, but a maintainer reviewing a change from a stranger wants one thing to look at.

The PR is open and waiting for review, so the code may change before it lands. The thing I'm taking from it applies well beyond this repo, though: when you override a default, read what the default was doing first. The part you're replacing is rarely the only thing it does.

First published on my blog. Cover photo: Bhullargraphic, CC BY-SA 4.0, via Wikimedia Commons (source).

What's happened: Morgan Stanley, Bank of America, JPMorgan, Wells Fargo and others are seeing third-party AI agents working inside customer accounts. Mostly with the customer's permission, in the sense that the customer typed their username and password into an assistant and said "sort my bills out". Some of those agents then did things nobody asked for, like ringing the bank's call centre. Morgan Stanley has started blocking outside agents. JPMorgan, Bank of America and Citi are restricting them, moving towards read-only access.

What stuck with me was one line from a bank executive, that they struggle to tell one agent from another, or whether an agent was authorised by the customer or has gone rogue. That's the whole problem, and it's not a model problem.

What the bank actually sees

If you've built a login flow, you already know why they can't tell.

An agent with your password drives a real browser. It loads the page, types into the same fields, clicks the same button and gets the same session cookie you would. From the server's side that session is you. The only signals left are behavioural: typing speed, mouse movement, odd hours, a headless browser fingerprint. Fraud teams use those, but they were built to spot an attacker pretending to be you, not your own assistant openly acting for you with your blessing.

And once the password has been handed over, the agent has everything you have. There's no smaller version of "logged in". It can read the balance and it can also set up a payee, because the website was designed on the assumption that whoever holds the session is the account holder.

I spend a lot of my working week on the other side of this. At work my team builds LLM pipelines that read email and make decisions, and I've done KYC onboarding and smart-meter consent journeys before that. The bit everyone underestimates in consent flows is the scope. "Can this thing see my data" and "can this thing act on my data" are different questions, and a password answers both with yes.

The money question

Jamie Dimon said on JPMorgan's earnings call on 13 October that the bank won't let "just any outside agent" in, and, according to CNBC, that people using them "should understand there's a liability transfer".

That phrase is doing a lot of work. US rules protect you against unauthorised transfers. If you gave an agent your credentials, a transfer it makes looks authorised, so getting your money back after the agent gets something wrong is not a given. I'm not a lawyer and I'd want to see how a real dispute plays out, but if I were a customer I'd take that as the bank telling me, politely, that it's on me.

To be fair to the banks, nobody has reported a confirmed loss from a rogue banking agent yet, and Morgan Stanley's spokesperson said it hadn't seen rogue agents on its platforms at all. The blocking is precautionary. But "we can't see them" and "they aren't there" are not the same statement, and the first one is the one the executives are admitting to.

The read-only route already exists

JPMorgan's position is more nuanced than "agents banned". It already lets agents read some data, balances for example, through aggregators like Plaid. What it won't allow is an agent logging in with your password and moving money.

Over here we've had a version of the right answer since 2018. UK Open Banking gives regulated third parties an API with explicit, scoped consent: you approve "read my transactions for 90 days" in your own banking app, the third party gets a token for exactly that, and you can revoke it without changing your password. Payments go through a separate consent with strong customer authentication on your side. None of it was designed with LLM agents in mind, but the shape is right.

So the fix banks are reaching for, read-only via an intermediary, is basically the first half of that model. The second half, letting an agent act, is where it gets hard.

What I'd want before letting an agent move money

If I were designing this on the bank's side, the list is not exotic. It's the same things we already do for any third-party integration, just taken seriously:

• The agent gets its own credential, never mine. A token issued to that agent, for that customer, that the bank can see, label and revoke. If an agent misbehaves you cut off the agent, not the customer.
• Scopes that match the job. "Read balances" and "pay this one bill up to £200" are different grants. Most of what people want from a money assistant needs the first one only.
• A human confirmation for anything that moves money. A push in the banking app saying "Muse wants to pay £84 to Thames Water, approve?" The agent can prepare the payment; it can't press the button.
• Requests that say who is acting. There are proposals for agents to sign their HTTP requests so a server can verify which agent and which provider it's talking to. I don't know which one will win, but some way of saying "this is an agent, here's whose" beats guessing from mouse movement.
• An audit trail the customer can read. Every action, which agent did it, under which consent.

The confirmation step is the one I feel strongest about, mostly because of my own side projects. My job-hunting workflow drafts emails to recruiters with an LLM, but nothing gets sent until I tap yes in Telegram. It's slower, and I've thought about removing it more than once. Then I read about an agent deciding on its own to phone a call centre, and I'm glad the yes is there.

If you're building agents

The takeaway for developers isn't "don't build finance agents". It's that driving someone's logged-in browser with their password is a shortcut that works right up until the other side notices, and the banks have now noticed. Use the official, scoped routes where they exist (aggregators, Open Banking APIs), ask for read access unless you truly need more, and design for a human to approve the actions that matter.

And if you're a customer: the Chase spokesperson's advice is boring and correct. Don't give your banking password to anyone, and that now includes the assistant on your phone.

First published on my blog. Cover photo: Joe Mabel, CC BY-SA 4.0, via Wikimedia Commons (source).

The official post lists the patched versions as v26.12.1, v24.22.1 and v22.23.4.

Dependencies were bumped as well: c-ares, OpenSSL (on 24 and 22), SQLite (on 22), Undici, and the bundled CA certificates, which now account for the eMudhra intermediate CA compromise.

The advisory only describes the Brotli bug in any detail. For the others I'm going from the titles and what I know about how those parts of Node get used, so read the rest as one working developer's interpretation rather than the official analysis.

The Brotli one

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder, and the advisory says it can allow remote code execution. A decompressor that can be talked into writing somewhere it shouldn't is about as classic as memory bugs get.

So the question for your app is where Node decompresses Brotli data that you didn't create, and I think it's more places than most people would guess. fetch() in Node is Undici, which transparently decompresses a content-encoding: br response, so any server-side fetch to a URL you don't control is in scope: link previews, webhooks that call back out, scrapers, RSS readers. My AI Radar workflow pulls from a dozen or so feeds every hour, and I'd be surprised if none of them served Brotli. Then there's anything that accepts compressed uploads or request bodies and passes them to zlib.brotliDecompress. If you only ever decompress your own assets the risk is lower, but "we only fetch from places we trust" has a way of stopping being true without anyone noticing.

The two TLS hostname bypasses matter too. The hostname check is the part of TLS that makes sure a certificate belongs to the host you meant to talk to, and without it you still get encryption, just possibly to the wrong party. The fullwidth digits one looks like a normalisation problem. Unicode has a second set of digits, ０１２３, which look like ordinary digits but aren't the same characters, and if one layer treats １２７.０.０.１ as a plain string while another converts it to 127.0.0.1, they can disagree about which host you're talking to. The medium one about non-canonical IPv4 addresses (octal, hex, fewer dots) seems to be the same family. And dns.resolve cutting names off at a NUL means good.example\0.evil.example could resolve as something other than what your code checked, which is exactly the pattern in an SSRF allowlist sitting in front of a fetch.

The snapshot one is subtle, and I found it the most interesting of the lot. Node keeps a small cache of random bytes so crypto.randomUUID() and randomInt() are quick, and if you build a user-land startup snapshot or a single executable application, that cache was being saved into it, so every process started from the same snapshot begins by handing out the same values. If you don't use snapshots or SEAs it doesn't affect you. If you do, and you use randomUUID() for anything that needs to be unguessable, patch that one quickly.

The low ones are mostly Permission Model bypasses, and this is the second release this year with path-matching issues there (July had CVE-2026-58043). I'd treat --permission as an extra layer and keep relying on containers and OS limits for the real isolation.

What I did

First I checked what was actually running, on the Mac, in CI and in the containers at home:

node -v
ssh kishan-server 'for c in $(docker ps -q); do
  printf "%s " "$(docker inspect -f "{{.Name}}" $c)"
  docker exec $c node -v 2>/dev/null || echo "-"
done'

Most of my Next.js apps run on a node:22-alpine image, and the official images had new tags within a few hours, so the fix was a rebuild that pulls the fresh base:

docker build --pull --no-cache -t seensooner-web:latest .

--pull is the bit that matters. Without it Docker reuses the node:22-alpine it already has, you redeploy, everything looks fine, and you're still on the old Node. I've been caught by that before. After the rebuild I ran node -v inside each container again to make sure it said v22.23.4, then bumped .nvmrc and the node-version in GitHub Actions. (If CI uses lts/* you'll get it automatically, but I prefer exact versions.)

Node 26 moves to LTS this month, 24 is active LTS and 22 is in maintenance, so it still gets security fixes. I'm staying on 22 for this one because it's a patch bump, and I'll move the apps to 24 in November once I've had time to test, rather than doing a major upgrade and a security patch on the same evening. If you're on 20 or older you aren't getting any of these fixes, and that's a bigger job than a rebuild.

First published on my blog. Cover photo: Victorgrigas, CC BY-SA 3.0, via Wikimedia Commons (source).

The two vulnerabilities are CVE-2026-109618 and CVE-2026-109619, and people have started calling them PHP2Shell. The PHP team rated both 9.2 on CVSS v4, and watchTowr went further and scored it 10. Both can lead to remote code execution without any authentication, and the reported range of affected versions is wide, PHP 5.4 all the way to 8.5.

If you're on a distribution package, the version number may not match those, because distros backport fixes into their own builds. Check your vendor's advisory rather than just php -v.

What the two bugs are

The GitHub advisories are titled "RCE via OOM corruption" and "RCE via stale global state", and I'll stay at the level they describe.

CVE-2026-109618 is about what happens when PHP runs out of memory partway through certain work. The operation stops in the middle, some request data is left half set up, and the cleanup code then runs over that broken state. According to the reports this path was spotted in a 2024 audit and never fixed, because nobody could agree on the fix and nobody had shown it was exploitable. I find that oddly relatable. Plenty of bugs in my own work have survived for exactly that reason.

CVE-2026-109619 is about state leaking between requests. A PHP worker handles many requests over its life, and if references to one request's data survive after that memory has been freed, a later request on the same worker can touch memory that now belongs to something else, which is a use-after-free. The advisories also say researchers showed it could disclose worker memory without authentication, which means things like session tokens and passwords from other people's requests.

Both affect the usual ways PHP is served: Apache mod_php (called out as the most urgent), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

A messy week for a disclosure

The plan was a coordinated release. PHP announced on 20 October that fixes were coming, and the advisories went up on GitHub on 21 October at 13:34 UTC, about 26 minutes ahead of the announced time. Before that, though, things leaked. It surfaced on Hacker News early, a proof-of-concept video was released by mistake, and Chainguard shipped patched builds ahead of the release, which meant anyone could diff the old and new code to find where the bugs were. Amazon reported seeing an attempt in its honeypots on 17 October, four days before the advisories went up.

Reports on exploitation don't agree with each other. CISA said on 21 October that it hadn't observed any, and told organisations to patch immediately or take PHP systems offline if they couldn't. watchTowr said the same day that it was seeing exploitation in its own honeypots. Cloudflare pushed temporary WAF rules, and a lot of public sector sites in Europe went offline as a precaution, which tells you how seriously people were taking it.

The bugs were found independently by Ryan Austin at Calif and by Wiz, and both used AI models as part of the work. I suspect that's what people will remember about this one after the patch is old news. PHP's core is decades of C with a lot of eyes on it, and if models can now walk through old C and find memory bugs faster than maintainers can review fixes, we'll see more weeks like this, in projects that often have one or two volunteers looking after them. The finding has sped up a lot, and the fixing still depends on a small number of people having the time.

Why it felt familiar

Ten months ago it was React2Shell for those of us on the JavaScript side. Different language and a different kind of bug, but a similar shape: in both cases the dangerous code was in the runtime or framework layer that turns an incoming request into something your code can use. You could have written perfect application code and still been exposed.

The stale state bug also maps quite neatly onto Node. A PHP-FPM worker carrying something from request A into request B is, conceptually, the same mistake as a Node server keeping per-user data in module scope, which is the kind of thing that turns up in code review now and then:

let currentUser: User | null = null;

export async function handler(req: Request) {
  currentUser = await getUser(req); // shared by every concurrent request
  return render(currentUser);
}

A Node process is long-lived by design, so anything at module level is shared across every request it serves. PHP's model was meant to make that kind of leak hard, because every request starts fresh, and this bug sat in the machinery that does the starting fresh.

What to do about it

Update to the fixed version for your branch. That's the actual fix, and the PHP team were clear that the stopgaps aren't complete. If you really can't update today, these were published as temporary measures:

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config, not with ini_set() or .user.ini, which apply too late, and restart the workers.
• On PHP 8.5, set fatal_error_backtraces=0 the same way.
• Keep post_max_size sensible (8M with no uploads, 32M if you take them), with upload_max_filesize below it, and limit request sizes at the web server or proxy.
• Use container or cgroup memory limits.
• On PHP-FPM, pm.max_requests=1 was mentioned as optional. It costs performance and doesn't replace patching.

; FPM pool, as a stopgap until you can upgrade
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M

If a server was exposed and unpatched during the window, I'd also think about rotating anything that lived in worker memory, like session keys, API tokens and database passwords, given the memory disclosure part.

On my own box I was fairly sure nothing was PHP, but fairly sure isn't sure, so:

docker ps --format '{{.Image}}\t{{.Names}}' | grep -i php
docker images --format '{{.Repository}}:{{.Tag}}' | grep -iE 'php|wordpress|nextcloud'

Nothing came back. It's all Node, Go, Postgres and the Supabase stack. I did nudge a couple of friends who run WordPress on shared hosting to check what PHP version their host was on, since that's about all you can do on shared hosting.

Node isn't immune to any of this. We have our own C++ runtime underneath, our own long-lived processes and our own framework serialisation layers, and Node's security release came out the same day with a Brotli decoder bug rated high (I wrote that one up separately). The thing I keep coming back to is how quickly you can get a fixed runtime into production on a random Wednesday: knowing which versions you run, having a build that pulls the new base image, and being able to redeploy in minutes without a ceremony. That part's in our hands whatever language we write.

First published on my blog. Cover photo: Charles J. Sharp, CC BY-SA 4.0, via Wikimedia Commons (source).

For a while I've had a personal n8n workflow watching my own search. It checked a couple of sites every 15 minutes and pinged me on Telegram when something new showed up. Friends kept asking if they could have it too, so last week I turned it into a public site, Doorstep, and this is mostly about the bit I got wrong first.

Version one was "Rightmove, but faster"

The first pitch was speed. Rightmove alerts used to be a daily email, so a 15-minute check felt like a real edge, and I built everything around that one promise: the form, the double opt-in, the alert email, the landing page.

Then I sat down to make the comparison table for that landing page, and to get a screenshot I set up a fresh Rightmove alert. They offer instant alerts now, push and email, as soon as a home is listed. My headline feature was something the biggest site in the country already did, for free, and probably had done for a while.

It was a mildly embarrassing evening. But I'd much rather find that out from my own comparison table than from the first person who signed up and wrote back to tell me.

So I asked a different question, which was what a renter still has to do by hand, and once I looked at it properly the answer was obvious. Each portal's alert only covers that portal. Agents list on Rightmove, OnTheMarket and sometimes both, landlords list directly on OpenRent, and to be thorough you need three alerts, three accounts, and the patience to work out that the flat in two different emails is actually the same flat. That's the product: one alert, several sites, and each home shown once.

Three sites, one list

Doorstep now checks Rightmove, OnTheMarket and OpenRent every 15 minutes for each saved search. Every site gets a small adapter that turns a search (area, radius, minimum and maximum rent, bedrooms, move date) into that site's URL format, and turns whatever comes back into one shape:

type Listing = {
  source: "rightmove" | "onthemarket" | "openrent";
  url: string;
  rentPcm: number;
  beds: number;
  street: string;
  postcodeDistrict: string;
  agent?: string;
  firstSeen: string;
};

I did try more. Zoopla, PrimeLocation and a couple of others sit behind Cloudflare's bot protection and return 403 to a request from a server, and I'm not going to fight that. Gumtree's radius search didn't behave consistently enough to trust, and SpareRoom is mostly rooms, which is a different search altogether. Three sources that work properly are better than six that sometimes do.

The part I enjoyed most was spotting the same home across sites. There's no shared ID between them. The photos are different, the titles are different ("2 bed flat" against "Two bedroom apartment"), and the full address is often hidden until you enquire. What turned out to be stable enough is a fingerprint of three things:

const fingerprint = (l: Listing) =>
  [l.beds, l.rentPcm, normaliseStreet(l.street)].join("|");

normaliseStreet lowercases the street, drops house and flat numbers, and expands or strips "Rd", "St", "Ave" and friends so that "Ballards Ln" and "Ballards Lane" come out the same. The same number of beds at the same rent on the same street is almost always the same flat. Occasionally it'll merge two different flats on one street at one price, but that's rare, and when it happens you see one card that links to both, which isn't the end of the world.

Each email then shows a home once, with "via Rightmove · also on OpenRent" underneath, so you can choose where to enquire. Sometimes the landlord-direct listing is the better way in.

The first real test was on 18 October, a 1-mile search around N12. Rightmove on its own had 3 new lets. Across all three sites there were 13 distinct homes, and 2 of those were listed on more than one site. That gap is the whole argument for the thing, and it's what the site leads with now instead of speed.

How it's put together

There's nothing clever in the stack. A Next.js front end serves the site and the signup form, n8n runs the 15-minute schedule, calls the adapters, dedupes and sends the emails, and Postgres on my self-hosted Supabase holds the searches, subscribers and fingerprints already sent. Signing up is double opt-in by email, with no accounts or passwords, and every alert has a one-click stop link.

Each subscriber's state is just the set of fingerprints they've already been sent, and a new listing is anything not in that set. That keeps the logic easy to think about, and it means a restart never sends anyone old homes again.

The disk incident

The first night after launch the box hit 96% disk. The load average had climbed, and Firecrawl (which also runs there) had fallen over because its message queue couldn't write anything.

The culprit was n8n. By default it saves execution data for every successful run, and my older personal workflow had been saving the full HTML of a search results page, around 2 MB, every 15 minutes, for months. The SQLite database had grown past 3 GB. The fix was one setting on the workflow, to stop saving data for successful executions. Failed runs still keep theirs, which is the only time I ever look anyway. Then I vacuumed the database with n8n stopped, and the box calmed down. On a laptop that default would never have mattered. On a small server it eventually catches up with you.

What still stops a proper launch

Two things. The first is email volume. Alerts go out through a Gmail account for now, which caps at roughly 500 messages a day. That's fine for friends and a few dozen people, and nowhere near enough beyond that, so before I share it widely it needs a proper sending domain through something like Resend, with SPF and DKIM set up so the alerts don't end up in spam.

The second is terms of use. Property portals generally don't allow automated access in their terms. Doorstep is gentle about it (one request per search every 15 minutes, no bulk crawling, and every card links straight back to the listing on their site rather than copying it), but I don't think that makes it fine, and if a site asks me to stop, I'll stop. It's a portfolio project and a personal tool first.

If you're renting in north London and want to try it, it's at doorstep.kishankanejiiya.tech. Next on my list is sorting out the sending domain.

First published on my blog. Cover photo: David Smith, CC BY-SA 2.0, via Wikimedia Commons (source).

The headline in 16.4 is that Cache Components are now the recommended way to build every app, and create-next-app switches them on by default. When Next 16 came out last year, cacheComponents: true was an opt-in. Existing apps don't get flipped for you, which I think is right, because it does change behaviour. With it on, everything is dynamic unless you mark it with "use cache", and the static parts of a page are prerendered as a shell while the dynamic parts stream in under <Suspense>. I'd moved most of my apps to it over the past year anyway, so this release mostly confirmed where things were heading.

There's also ensureStatic, which lets you say a route must stay static so the build fails if something dynamic sneaks in. I like the idea a lot for pages that are built from a data file, but check the release notes for exactly how to apply it, as I'm still getting used to it. Then there are new navigation and prefetch APIs, which I've read about and haven't used, so I won't try to explain them. And next upgrade --agent, which hands the upgrade to a coding agent along with the migration notes. I tried it on my smallest app, where there was almost nothing to change, so it bumped the packages, ran the build and stopped. Not much of a test. I'd want to see it on a messier upgrade, and I'd still read the diff. The rest of the release is performance: a smaller disk cache, lazy server HMR, a shared Turbopack runtime and smaller production bundles. I did notice the disk cache, since the box at home is never far from full.

React 19.3

React 19.3 came out on 9 September, bundled into 16.4. Two experimental features went stable, <ViewTransition> and Fragment refs, and there are no breaking changes, which is why it's 19.3 and not 20.

<ViewTransition> wraps the browser's View Transitions API in a component. React decides when a transition starts (a navigation, a startTransition, a Suspense reveal) and you say what should animate. On AI Radar I'd wanted the small cover image in the feed to grow into the big one on the issue page, so that's where I tried it:

// feed
import { ViewTransition } from "react";

<Link href={`/issue/${issue.id}`}>
  <ViewTransition name={`cover-${issue.id}`}>
    <img src={issue.cover} alt="" width={120} height={80} />
  </ViewTransition>
  <h2>{issue.title}</h2>
</Link>

// issue page
<ViewTransition name={`cover-${issue.id}`}>
  <img src={issue.cover} alt="" width={960} height={640} />
</ViewTransition>

The same name on both sides and the browser morphs one into the other. Browsers without View Transitions just navigate normally. Names have to be unique on the page when the transition runs, and it's worth switching the animation off for people who've asked for reduced motion:

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;
  }
}

Fragment refs let you put a ref on a <Fragment> and reach its DOM children without a wrapper div. I've only had one place where a wrapper would have broken a CSS grid, and I'd read the docs for the exact API rather than trust my memory of it.

The upgrade itself was the usual:

npm install next@16.4 react@19.3 react-dom@19.3 eslint-config-next@16.4
npm run build

Most apps built and passed their smoke tests first time. A couple needed small fixes, mainly a component reading cookies() without a Suspense boundary above it, which older versions had let me get away with, and an old experimental ViewTransition import. My deploys build on the Mac and ship only the standalone output, so a bad upgrade would have been one image to roll back. I didn't need to.

First published on my blog. Cover photo: Alexander Novikov, CC BY-SA 4.0, via Wikimedia Commons (source).

Both run on the same small box: two cores, under 6 GB of RAM, with n8n and Postgres in Docker next to about two dozen other containers. That limit came up again and again, and it explains a few of the choices below.

Keeping up without drowning

Things move fast enough at the moment that I'd started to worry about falling behind. A new model one week, a Next.js release the next, a React advisory, a tool that everyone is suddenly using. I was picking it all up from X, a couple of newsletters, Hacker News when I remembered, and a WhatsApp group. Lots of duplicates, lots of noise, and I'd still miss things that mattered.

Before building anything, I spent an evening going back through the previous month and noting where the links I'd actually found useful had come from. It was a shorter list than I expected: Hacker News, a few subreddits, dev.to, GitHub (new repos picking up stars quickly), Lobsters, and some Medium. The newsletters were mostly repeating those a day or two later, which was a bit deflating, but it made the design easy.

So AI Radar reads those sources every hour and sends me the best few links on Telegram. Hacker News comes in through the Algolia search API, filtered by points and age. Reddit comes in over RSS, because the JSON API returns 403 to my server's IP while RSS works fine (I don't know why, and I stopped caring once RSS worked). dev.to has a public API you can query by tag. GitHub search gives me recently created repos sorted by stars. Lobsters has a JSON feed, and Medium has tag feeds.

Everything ends up in one Code node called "Rank & Format". It turns each item into the same shape, {title, url, source, score, at}, gives it a score from points, comments, age and a boost for keywords I care about, and picks the top handful.

I set two rules before writing any of it. The first was that a link must never be sent twice. The same article turns up on HN, Reddit and Lobsters, sometimes days apart, and getting it three times is exactly the noise I was trying to get rid of. So URLs are normalised (tracking parameters, www. and trailing slashes stripped) and every sent URL is remembered for 30 days. The second was that React and Next.js always get a look in. AI news drowns everything else at the moment, so the first three slots in each message are kept for React and Next.js items when there are any worth sending, and AI and general full stack links fill the rest.

Where that "already sent" list lives turned out to matter a lot, which I'll come back to.

The digest now sits in a Telegram chat I look at a few times a day. Most hours it sends four or five links and I open one or two, which feels about right. If I was opening all of them the ranking would be too strict, and if I opened none it'd be noise again.

A job hunter that waits for my yes

The second workflow came from a more practical need. I wanted to watch for roles in the UK at companies that hold a licence to sponsor visas, which narrows things down a lot and makes ordinary job alerts mostly useless.

The government publishes the register of licensed sponsors as a CSV, and it's around 122,000 organisations. The names rarely match how companies appear on job boards ("Acme Technologies Ltd" on the register, "Acme" on the advert), so a plain lookup misses most of them. I load the register into Postgres weekly and match on a normalised name plus trigram similarity:

create extension if not exists pg_trgm;

select name, similarity(norm_name, norm_company($1)) as score
from jobhunt.uk_sponsors
where norm_name % norm_company($1)
order by score desc
limit 1;

norm_company lowercases the name and strips things like "ltd", "limited", "plc", "uk" and punctuation. With a threshold around 0.6 it's right far more often than it's wrong, and borderline matches get flagged for me to look at rather than trusted.

Three times a day the workflow pulls new roles from job board searches and throws away anything it has already seen, anything that's a contract, and anything from my current employer. What's left gets checked against the sponsor register. Then a cheap model reads the description and answers a few plain questions: is this really front end or full stack, what level is it, and is there a sentence saying they won't sponsor. Only the roles that pass go to a stronger model, which drafts a short cover letter. And then the draft comes to me on Telegram with Yes and No buttons, and nothing is emailed unless I press Yes.

The two-model split was a cost lesson. My first version sent every job to the big model and spent about a dollar on a handful of roles, which is fine once and silly three times a day. Now Claude Haiku does the screening for well under a cent a job, and Sonnet only writes letters for the few that pass. The letters are just as good, and it costs a fraction of what it did.

The approval step isn't going anywhere. An automation that emails people in my name without me reading it first is a risk to my reputation, and the time it would save is a few seconds a job. That's not a trade I want.

Where n8n bit me

Some of these cost me more time than I'd like to admit.

The Code node sandbox has no URL class. new URL(link) doesn't fail in any way you'd notice from the canvas, it just silently dropped every item that went down that path, and I spent the best part of an hour convinced a search was returning nothing. I swapped it for a small regex:

function parseUrl(u) {
  const m = /^(https?):\/\/([^/?#]+)([^?#]*)(\?[^#]*)?/i.exec(u || "");
  return m ? { host: m[2].toLowerCase(), path: m[3] || "/", query: m[4] || "" } : null;
}

The Merge node tops out at 10 inputs, and with 11 sources I had to merge in two groups and then merge the merges. Not hard, just odd to discover halfway through.

n8n import:workflow needs an id in the JSON, and without one you get a SQLite NOT NULL error that doesn't mention ids anywhere.

The one that actually hurt was static data. Re-importing a workflow wipes it, and that's where I'd put the "already sent" list for AI Radar. The first time I fixed a typo and re-imported, the next digest was full of links I'd already seen, which was the one thing I'd promised myself it would never do. Anything that has to survive a deploy now lives in Postgres, and static data is only a cache. On a related note, runs started with the CLI execute command don't save static data either, so testing from the terminal behaves differently from the scheduled run. If state matters, test with the real trigger.

And running CLI commands inside the live container clashes with the task runner on its broker port, so one-off commands need a different N8N_RUNNERS_BROKER_PORT.

Why not just write a service

I'm a developer, so the obvious question is why I didn't write a Go service with a cron job. For the core logic I do write code, it just lives in Code nodes. What n8n gives me is the dull surrounding stuff: schedules, retries, credentials, Telegram buttons, and an execution log I can open on my phone. That last one is the real reason. When a run fails at 8am I can see which node failed and what it was given, without opening a laptop or SSH-ing anywhere.

If one of these grows into something other people rely on, the logic will move into a proper service. That's more or less what happened with Doorstep, which also started life as a personal alert workflow.

First published on my blog. Cover photo: falco, CC0, via Wikimedia Commons (source).

Getting it running took an evening. Working out what I'd nearly exposed took a lot less.

The home server is a small Ubuntu machine with two cores and under 6 GB of RAM, running roughly 25 Docker containers. Nothing on it has an open inbound port. Public hostnames all go through one Cloudflare Tunnel, where cloudflared on the box makes an outbound connection to Cloudflare and each hostname maps to a port on 127.0.0.1, and for admin I use Twingate. Firecrawl's compose file brings up the API, workers, a Playwright service, Redis and RabbitMQ, with the API on port 3002. The plan was the usual: a DNS record, a tunnel rule pointing firecrawl.<my domain> at 127.0.0.1:3002, and call it from n8n.

No auth, and a view of the whole LAN

Before adding the route I went looking for where to set the API key. The hosted version wants Authorization: Bearer fc-... on every request, so I assumed the self-hosted one would have an env var for it.

It doesn't. Self-hosted Firecrawl has no authentication of its own. There's a USE_DB_AUTHENTICATION setting, but that's for their Supabase-backed multi-tenant setup, and with it off (the default when you self-host) every request is accepted. My tunnel route would have turned it into a free, anonymous headless-browser scraper for anyone who found the hostname. People would have scraped things from my home IP, and the box would have fallen over, because it can barely run Firecrawl for one person.

Then I thought about what it could reach. A scraper is, by design, a thing that fetches whatever URL you give it, and when it runs inside your network that includes your network. So I tried it from the box:

curl -s localhost:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url":"http://localhost:5678"}'
# rejected

curl -s localhost:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url":"http://10.0.0.80:5678"}'
# returns the n8n login page as markdown

It rejects the literal hostname localhost and nothing else. The machine's own LAN IP works, and so do the other private ranges, which means anything on my network with a web UI was reachable: n8n's login page, uptime-kuma, the Supabase studio, and I'd guess the router's admin page as well. Most of those need a login, but "most" is carrying a lot in that sentence, and some services trust requests from the local network more than they should.

That's server-side request forgery, the same class of bug behind some very large cloud breaches, and I'd been about to set one up in my own house on purpose.

A gateway on the port the tunnel already uses

I didn't want to touch the tunnel config, because on this box the cloudflared config is root-owned and every edit needs a sudo step. So I took Firecrawl off the host port and put a tiny nginx container on 3002 instead, which is where the tunnel was going to point anyway.

Cloudflare Tunnel → 127.0.0.1:3002  nginx gateway (auth, rate limit)
                          │  docker network: firecrawl_backend
                          ▼
                     api:3002       Firecrawl (not published to the host)

The Firecrawl API isn't published on any host port the tunnel uses now. Only the gateway can reach it, over the compose network. This is the config, with the key replaced:

map_hash_bucket_size 256;

# Accept the key as X-API-Key or as Authorization: Bearer <key>
map $http_x_api_key $key_ok_header {
    default 0;
    "REPLACE_WITH_64_CHAR_KEY" 1;
}
map $http_authorization $key_ok_bearer {
    default 0;
    "Bearer REPLACE_WITH_64_CHAR_KEY" 1;
}
map "$key_ok_header$key_ok_bearer" $authorized {
    default 1;
    "00"    0;
}

# Cloudflare tells us who the real client is
limit_req_zone  $http_cf_connecting_ip zone=per_ip:10m rate=5r/s;
limit_conn_zone $http_cf_connecting_ip zone=per_ip_conn:10m;

server {
    listen 3002;
    client_max_body_size 1m;

    # Health check stays open so uptime-kuma can probe it
    location /v0/health/ {
        proxy_pass http://api:3002;
    }

    location / {
        if ($authorized = 0) { return 401; }

        limit_req  zone=per_ip burst=20 nodelay;
        limit_conn per_ip_conn 10;

        proxy_pass http://api:3002;
        proxy_read_timeout 120s;
    }
}

Five requests a second with a burst of 20, and no more than 10 open connections per client IP. That's plenty for n8n, and it stops anyone who gets hold of the key from melting the box. The key is 64 random characters from openssl rand -hex 32, kept in a file on the server and in my n8n credentials, and nowhere near git.

The first time I started the gateway, nginx refused to load:

could not build map_hash, you should increase map_hash_bucket_size: 64

nginx keeps map keys in a hash table with a 64-byte default bucket size, and a 64-character key (71 with Bearer in front) doesn't fit. Putting map_hash_bucket_size 256; at the top of the file fixed it. It has to be in the http context before the maps, and in the official nginx image files in conf.d are already included inside http, so the top of your own file works.

Then the checks:

# no key
curl -s -o /dev/null -w '%{http_code}\n' https://firecrawl.<domain>/v1/scrape
# 401

# wrong key
curl -s -o /dev/null -w '%{http_code}\n' -H 'X-API-Key: nope' https://firecrawl.<domain>/v1/scrape
# 401

# health, no key
curl -s -o /dev/null -w '%{http_code}\n' https://firecrawl.<domain>/v0/health/liveness
# 200

With a valid key, scraping a normal public page works and n8n is happy.

None of this fixes the SSRF itself, mind. Anyone with the key can still ask for http://10.0.0.80:.... The only key holders are me and my own workflows, so I can live with that for now. The proper fix is to put the Playwright and worker containers on a network that can reach the internet and not the LAN, and that's next on my list, along with Cloudflare Access in front so a leaked key on its own isn't enough.

If you self-host tools like this, I'd assume the self-hosted version has less security than the hosted product rather than the same. The hosted one has an auth layer, abuse detection and people watching it, and the compose file usually has none of that. And before giving anything a public hostname, it's worth asking who can call it and what it can reach that the caller can't. For anything that fetches URLs (scrapers, link previewers, PDF renderers, webhook testers, image proxies) the second question matters more, and I nearly didn't ask it because the tunnel made exposing things so easy.

First published on my blog. Cover photo: Basile Morin, CC BY-SA 4.0, via Wikimedia Commons (source).

There's no new package to learn. The Go compiler is just typescript now:

npm install -D typescript@7
npx tsc --version
# Version 7.0.x

tsc is the native binary, and the @typescript/native-preview package and tsgo command I'd been trying since last year are for nightlies now, so I deleted the preview package and the extra script I'd added to compare the two. In VS Code, run "TypeScript: Select TypeScript Version" and pick the workspace version, otherwise you're still using whatever the editor bundles.

My projects aren't big. The largest is a Next.js app with a Go backend next to it, and the rest are smaller Next.js apps sharing the same tsconfig base. A cold tsc --noEmit on the biggest one went from somewhere around 14 seconds to under 2, and the smaller ones are now basically instant. That's roughly five to seven times faster for me. Microsoft quotes 8x to 12x on large codebases (the VS Code build dropping from 125.7 seconds to 10.6), which makes sense, because small projects spend more of their time starting up and reading node_modules types, and that part doesn't speed up as much. In CI the type-check step went from most of a minute to a few seconds, and the job is now mostly npm ci.

But the editor is the bigger change, as I expected. Go-to-definition works before I've finished finding the file I wanted, and renaming a field in a shared type updates the errors across the project more or less as I type.

The new compiler checks files in parallel, and you can tune it with --checkers (type-checker workers), --builders (parallel project builds in -b mode) or --singleThreaded. On my laptop the defaults were already the quickest. Our CI runners only have 2 vCPUs, though, and --checkers 2 was a little faster there and used less memory, which helps because the same job runs the Next.js build afterwards.

Almost everything else moved over without fuss. Same errors, same messages, same tsconfig.json. The only config changes were the deprecation warnings TypeScript 6 had been showing me for months and I'd been ignoring, so if you're on 6 with a clean build, you're probably fine.

The one that didn't move

One project has a small script that reads my API route files with the TypeScript compiler API and generates a client from the exported handler types. It's a few hundred lines of ts.createProgram and checker.getTypeAtLocation, and it doesn't work with 7, because the old JavaScript API isn't part of the native compiler. A new API is in progress, but I didn't want to rewrite against it this month, so that one script keeps TypeScript 6 under an alias:

{
  "devDependencies": {
    "typescript": "^7.0.0",
    "typescript-6": "npm:typescript@^6.0.0"
  }
}

// scripts/gen-client.ts
import ts from "typescript-6";

The project type-checks with 7 and the generator reads the code with 6. It's a bit ugly, but it's one import and easy to delete later. If anything in your toolchain imports typescript as a library (ts-morph and friends), check its issue tracker before upgrading, because that's where the trouble is.

For everything else I'd clear the 6.x warnings, bump to 7, switch the editor to the workspace version, and get on with the day.

First published on my blog. Cover photo: BWard 1997, CC BY 4.0, via Wikimedia Commons (source).

Before any code gets written

For anything bigger than a one-file change I start in plan mode. It reads the code, proposes what it's going to do, and I read the plan before a single file changes. I was most tempted to skip this step early on, because it feels slow, but it's where I save the most time. Rejecting a bad plan takes a couple of minutes. Rejecting a bad implementation means reviewing the whole thing first, and then rejecting it anyway.

What I'm looking for in a plan is usually one of three things: it wants to touch files I didn't expect, it wants to add a dependency, or it's about to invent a new pattern when the repo already has one for exactly this. One of those comes up more often than not, and a sentence back usually sorts it out before anything is written.

The other thing that matters before any code is the size of the task. "Add pagination to the meters table, server side, using the existing usePaginatedQuery hook" gets a good result. "Improve the meters page" gets a diff I don't want to read. I break work down the way I would for a new joiner on the team: one behaviour, roughly one PR's worth of change, and a clear idea of what done looks like. If I can't describe done in a sentence, I split it again.

Tests, hooks and the boring rules

On work code the deal is tests first, or at least tests in the same change. I'll often write the cases myself as a list in the prompt, especially the edge cases I actually care about, and let it write the test code around them. Then I read the test diff before the implementation diff, because a model that wants green ticks will occasionally make the test agree with the code rather than the other way round. If the tests are right, the rest is much easier to judge. For UI work I add a Playwright check for the main flow too. It's slower, but it catches the "compiles, renders, button does nothing" sort of bug that unit tests walk straight past.

Hooks run shell commands at points in a session, like after a file edit or before a command runs. I only have a couple. After an edit, the formatter and type checker run on the changed files, so errors show up straight away instead of when I go looking. And before a command, anything that touches .env files or pushes to main gets blocked. That second one isn't really about the model misbehaving. I just don't want something that important to depend on anyone remembering, me included.

Subagents I use for one thing, which is keeping the main conversation clean. "Find every place we format currency and list the patterns" means reading a lot of files, and I'd rather a subagent did that and came back with a short answer. Skills cover the things I repeat: one for our component conventions at work, one for the deploy pattern on my home server. They're just folders with instructions and the odd script, and they only load when they're relevant. I did spend a few weeks building fancier multi-agent setups, and I've stopped. For the kind of work I do, one well-briefed session does better than several agents passing notes to each other.

My CLAUDE.md files are shorter now than they were a year ago, twenty or thirty lines, and each line is something it got wrong at least once, written as an instruction. When one grew to a few hundred lines the important rules got lost in it. Same with memory. It's useful, but I prune it, because an out-of-date note is worse than no note at all (it'll follow an instruction that stopped being true months ago, very confidently).

Reviewing what comes back

I review every diff the way I'd review a pull request from someone smart who joined last week. Good intent, no knowledge of our history.

git diff --stat          # did it touch what I expected?
git diff -- '*.test.*'   # tests first
git diff                 # then the rest, file by file

If the stat shows a file I didn't expect, I ask why before reading anything else. Sometimes there's a good reason. Other times it's a drive-by "improvement" that gets reverted. And the rule I set myself last year still stands: if I can't explain a change without reading its summary, it doesn't get committed.

Anything touching auth, user input, file paths, SQL or network calls also gets a second session with one job, which is to review the diff for security problems with fresh context and no attachment to code it just wrote. It finds real things. A path built from user input that wasn't normalised. A server action that checked there was a session but not that the record belonged to that user. A dangerouslySetInnerHTML fed from a CMS field. None of these are exotic, and that's why they slip through when you're tired. Since React2Shell in December I also ask it to check dependency versions against recent advisories whenever package.json changes. That doesn't replace npm audit or Dependabot, but it reads the advisory text, and they don't.

What I still do myself

Data models and API shapes I write by hand, because those decisions outlive the code and the generic answer is usually wrong for us. Anything with tricky concurrency or caching I'll have it explain, but I write it. And the first version of a new pattern is mine too: once it exists in the repo it can copy it well, but if it has to invent one, you get something very average. (Posts like this one are also mine, for what it's worth.)

Cost-wise, a personal plan is a fixed monthly amount, which is fine for side projects. Where I've been careful is API usage in my own automations, because there the bill grows with every call, so cheap work goes to a small model and only the hard part goes to a big one. I'll write that up properly when I do a post on my n8n workflows. At work the maths is simple enough. If it saves a senior engineer a couple of hours a week it has paid for itself many times over, and the cost I actually notice is attention, because reviewing is tiring and a tired reviewer approves things they shouldn't.

It's made me quicker at the parts of the job that were never the hard parts, and, a bit to my surprise, more careful about the rest.

First published on my blog. Cover photo: Shixart1985, CC BY 2.0, via Wikimedia Commons (source).

So this is my pass over it, in roughly the order I'd care about each thing, with a note on whether it's in code I actually ship.

ES2025

ES2025 was approved last June. Every current browser has most of it, and so does Node 22 and up.

The one I've used most is iterator helpers. They're the array methods you already know (filter, map, take, drop, flatMap, reduce, some, every, find) but on any iterator, and lazy:

const firstTenIds = rows
  .values()
  .filter((r) => r.active)
  .map((r) => r.id)
  .take(10)
  .toArray();

Nothing gets built in the middle. With a generator or a big Map, each step pulls one item at a time, and take(10) stops the whole chain once it has ten. There's also Iterator.from() to wrap anything iterable. Most of my use is on Map.prototype.values() and generators in Node scripts, where I used to spread everything into an array just so I could call .filter on it, which always felt a bit silly for something with a few hundred thousand entries.

Then the Set methods, which I've wanted for about as long as I've written JavaScript:

const before = new Set(["n12", "n3", "n2"]);
const after = new Set(["n12", "n20"]);

after.difference(before);    // Set { "n20" }      added
before.difference(after);    // Set { "n3", "n2" } removed
before.intersection(after);  // Set { "n12" }
before.isSubsetOf(after);    // false

There's union, intersection, difference, symmetricDifference, isSubsetOf, isSupersetOf and isDisjointFrom. I had a little setDiff helper that had been copied into several repos over the years, slightly different in each one. It's gone now, and these are in pretty much everything I write. If you only pick one thing from this post, pick these.

Promise.try is smaller. It runs a function and hands you a promise whether the function was sync, async, or threw before it got going:

const result = await Promise.try(() => parseConfig(input));

Before, a synchronous throw in the set-up of a promise chain could escape the chain entirely, and you'd find out from an unhandled error somewhere else. I use it in one retry helper where the callbacks can be either kind, and that's about it.

RegExp.escape is the one that fixes a real bug class:

const pattern = new RegExp(`^${RegExp.escape(userInput)}$`, "i");

I've seen hand-rolled escape functions miss a character more than once. Any search box that builds a regex from what someone typed wants this. In my case it replaced a regex whose whole job was escaping other regexes, which is the kind of line nobody wants to review and everyone approves anyway.

And JSON modules with import attributes:

import config from "./config.json" with { type: "json" };

The with { type: "json" } bit isn't decoration. It tells the runtime what it's allowed to load, so a server can't hand you JavaScript when you asked for JSON. I use it in Node scripts. In app code nothing changes, because bundlers have handled JSON imports for as long as I can remember.

ES2025 also has Float16Array, RegExp modifiers and duplicate named capture groups. I haven't needed any of them yet, and I'm not going to pretend I have.

Temporal

This is the big one. Temporal replaces Date, and it's been "nearly ready" for roughly as long as I've been working.

Firefox shipped it last year. Chrome shipped it in Chrome 144 in January. And this month it reached Stage 4 at TC39, so it goes into ES2026.

const now = Temporal.Now.zonedDateTimeISO("Europe/London");
const meeting = now.add({ days: 1 }).with({ hour: 9, minute: 30 });

meeting.toString();
// 2026-03-16T09:30:00+00:00[Europe/London]

const d = Temporal.PlainDate.from("2026-03-29");
d.add({ months: 1 }).toString(); // "2026-04-29"

Values are immutable, months start at 1 like a normal person would expect, and time zones are real objects instead of something you hope the server got right. It also has separate types for a date with no time (PlainDate), a wall-clock time in a particular place (ZonedDateTime), and an exact moment (Instant). Date never let you say which of those you meant, and I think most date bugs I've seen come from exactly that.

My day job involves a lot of energy market data, which is all half-hourly settlement periods in UK time. The clocks go forward on 29 March this year, which gives you a 46-period day, and when they go back in October you get a 50-period day. Every one of those has been a bug at some point in some codebase I've worked on (sometimes the same bug, fixed twice, in two places). Temporal gets them right by default, because it does the arithmetic in the time zone you gave it.

Am I using it? Not in the browser yet. Safari doesn't have it, and our users are on whatever browser their IT department installed. I'm using the polyfill in one internal tool to get used to the API, and for new date logic I write it the Temporal way, so the switch later is mostly deleting an import.

ES2026, nearly

ES2026 should be approved in June. These are at Stage 4 already or close enough that I'd be surprised if they moved.

using is explicit resource management. Something gets cleaned up when it goes out of scope:

{
  await using db = await openConnection();
  const rows = await db.query("select 1");
} // db[Symbol.asyncDispose]() runs here, even if query throws

It's try/finally without the nesting, and it's handy for file handles, locks and test fixtures. I use it in Node 24 scripts. Not in browser code yet.

Math.sumPrecise adds up numbers without the floating point error piling up as it goes:

[0.1, 0.2, 0.3].reduce((a, b) => a + b); // 0.6000000000000001
Math.sumPrecise([0.1, 0.2, 0.3]);         // 0.6

It isn't decimal maths, but for totals on a dashboard it's what you wanted all along. I'm not using it yet, and for money we already store integer pence, so it matters less to me than it might to you.

Map.getOrInsert does the "check, set a default, return it" dance in one call, and getOrInsertComputed takes a callback so the default is only built when it's needed:

const byArea = new Map();
for (const home of homes) {
  byArea.getOrInsert(home.postcode, []).push(home);
}

Too new for me to rely on yet, but I can already think of a few places it'll tidy up.

Error.isError(x) tells you whether something really is an Error, even across realms (iframes, vm contexts) where instanceof gives you the wrong answer. That's mostly useful in logging and error-reporting code. And Uint8Array gets fromBase64(), toBase64(), fromHex() and toHex(), which replace the btoa/atob workarounds that only ever worked on "binary strings" and fell over on anything outside Latin-1:

const bytes = Uint8Array.fromBase64(payload);
const hex = bytes.toHex();

I'm using the base64 ones in a small secrets tool where the key lives in the URL fragment. Error.isError I haven't reached for yet.

How I decide what to use

At work the rule is dull and it works: if a feature is Baseline "widely available", or the code only runs in Node, use it. If it's only "newly available", use it behind a polyfill or where we control the browser. Anything else waits.

Side projects get a looser rule, because the worst case is that I break my own site and fix it on a Sunday.

Checking Baseline on MDN takes about ten seconds, and it has stopped me shipping something Safari didn't support more than once. I'd check it before reaching for anything on this list.

First published on my blog. Cover photo: Uoaei1, CC BY-SA 4.0, via Wikimedia Commons (source).

I'd been writing server actions as if they were private functions, because that's how they feel. You put "use server" at the top, import the function into a component and call it like any other async function. Nothing about it looks like an API. But it is one: when you export a function from a "use server" file, Next.js gives it an ID and exposes it so the browser can call it, and anyone who can load your site can find that ID and POST whatever arguments they like. TypeScript types don't exist at runtime either, so an action declared as (id: string) can just as easily receive an object, an array or a 5 MB string.

So I've started writing every action the way I'd write a Go handler. Assume the input is hostile, check who's calling, and only then do the work.

Parse first, then check the user

I use zod, though any runtime validator does the job. What matters is that the schema runs on the server, inside the action, before anything else happens:

"use server";

import { z } from "zod";
import { requireUser } from "@/lib/auth";
import { db } from "@/lib/db";

const RenameReport = z.object({
  reportId: z.string().uuid(),
  name: z.string().trim().min(1).max(120),
});

export async function renameReport(input: unknown) {
  const user = await requireUser();
  const { reportId, name } = RenameReport.parse(input);

  await db.report.update({
    where: { id: reportId, orgId: user.orgId },
    data: { name },
  });
}

The parameter is typed unknown on purpose. It forces me to parse before I can touch anything, and it's honest about what actually arrives over the wire. Forms get the same treatment with FormData:

export async function subscribe(formData: FormData) {
  const { email } = z
    .object({ email: z.string().email().max(254) })
    .parse(Object.fromEntries(formData));
  // ...
}

After the middleware bypass last March I'd already moved auth checks for pages next to the data, but actions need it too, and they're easy to miss. So every action that touches user data starts with requireUser(), and the query is scoped to that user. In the example, where: { id: reportId, orgId: user.orgId } means a perfectly valid, logged-in user still can't rename someone else's report by guessing an ID. I've seen that exact access-control bug in code review more than once, in apps written by good developers. The helper itself is tiny:

// lib/auth.ts
import "server-only";
import { cookies } from "next/headers";

export async function requireUser() {
  const token = (await cookies()).get("session")?.value;
  const user = token ? await verifySession(token) : null;
  if (!user) throw new Error("Unauthorised");
  return user;
}

That import "server-only" line is on every module that reads secrets, talks to the database or verifies sessions now. The server-only package does nothing at runtime; its only job is to fail the build if a client component imports the file, so accidentally shipping the DB client to the browser shows up as a red build instead of an incident.

Secrets live somewhere else

One of the December follow-ups, CVE-2025-55183, exposed server function source code, and what I took from it is that server code shouldn't be relied on to stay secret. I had things like this lying around:

"use server";

const API_KEY = "sk_live_..."; // hardcoded "just for now"

export async function sendAlert() {
  await fetch("https://api.example.com/send", {
    headers: { Authorization: `Bearer ${API_KEY}` },
  });
}

Now secrets only come from the environment, read at call time in a server-only module, and never sit in the file that holds the action:

// lib/mailer.ts
import "server-only";

export async function sendAlert(to: string) {
  const key = process.env.MAILER_KEY;
  if (!key) throw new Error("MAILER_KEY missing");
  // ...
}

The action file imports sendAlert and has nothing sensitive in it, so if its source ever leaks again it makes for very dull reading.

Because actions are endpoints, they can be hammered like endpoints too. Anything that sends email, calls an LLM or runs a heavy query gets a limit. On my own box that's a simple fixed window in Postgres, keyed by user ID or IP:

export async function generateSummary(input: unknown) {
  const user = await requireUser();
  await rateLimit(`summary:${user.id}`, { max: 10, perSeconds: 3600 });
  // ...
}

On Doorstep the subscribe form also sits behind Cloudflare, so there's a second limit at the edge as well.

Patching without relying on me

December showed me how much depended on me seeing the right post on the right evening, so every repo now has the boring automation. Renovate (Dependabot would do) opens PRs for next, react and react-dom the day they're published, with security updates labelled and kept out of the grouped ones. CI runs an audit and fails on anything high or critical. Versions are pinned exactly and installs use npm ci, so what I tested is what ships, and when a security PR merges the Docker image is built with --pull and no cache so a stale layer can't keep the old package around.

# .github/workflows/ci.yml (the relevant step)
- run: npm ci
- run: npm audit --omit=dev --audit-level=high
- run: npm run build

None of that would stop a zero-day. It just shrinks the gap between the fix existing and the fix running, which in December was the bit that mattered. I still use server actions everywhere and I'm not going back to hand-writing an API route for every form. I just write them like the public endpoints they are.

First published on my blog. Cover photo: Rohini, CC BY-SA 4.0, via Wikimedia Commons (source).

I've spent most of the days since on it, at work and on my own projects. These are my notes.

What broke

If you use the App Router, your server and the browser talk to each other in a format called Flight. It's how React sends a rendered server component tree down to the client, and it's also how the client calls a server function. When a form submits to a "use server" action, React serialises the arguments, POSTs them to your server, and deserialises them there before your function runs.

That last step is where it went wrong. The deserialiser in react-server-dom-webpack (and the -parcel and -turbopack builds of the same code) trusted the shape of what it was given far more than it should have, and a carefully built payload could get the decoding step to reach things it was never meant to touch, and from there run code inside your Node process.

What makes it worse than the usual "please update your dependency" advisory is when it happens. It's before any of your code runs, so a server action that validates its input perfectly and checks the session is no help, because the bug is in turning the request body into arguments in the first place. And you didn't even need server actions. If the RSC server bundle is in your app, the endpoint that decodes Flight requests exists, so an app with no "use server" functions at all was still exposed.

I'm not going to describe the payload. Public proof-of-concepts appeared within about a day, and AWS reported exploitation attempts from known groups within hours of disclosure, so it's safest to assume scanners have already been at anything you have that's public.

Who is affected

Next.js has its own ID, CVE-2025-66478, because it bundles a vendored copy of the React server packages. That means bumping react in package.json doesn't fix a Next app. You need the patched next.

Next.js 13.x and 14.x stable aren't affected, and neither is the Pages Router, plain client-side React (a Vite SPA, CRA) or React Native. If your React never runs on a server, you can stop reading here. Other RSC frameworks (React Router's RSC mode, Waku, the Vite and Parcel RSC plugins) shipped their own patched releases, so check their changelogs if you use one.

What I did

My side projects are small and all live on one box, so for me this was a contained job, but I did it in a deliberate order.

First an inventory, of every repo and not just the ones I remembered being on Next 15 or later:

for d in ~/Desktop/Git/profile-projects/*/web; do
  printf '%-45s ' "$d"
  (cd "$d" && npm ls next react-server-dom-webpack --depth=0 2>/dev/null | grep -Eo '(next|react-server-dom-webpack)@[0-9.]+' | tr '\n' ' ')
  echo
done

npm ls reports what's actually installed, which is what you want here. A ^15.3.0 in package.json tells you nothing about what the lockfile resolved to.

Then upgrade and rebuild from clean:

npm install next@latest react@latest react-dom@latest
rm -rf .next node_modules && npm ci && npm run build

Vercel also put out npx fix-react2shell-next, which bumps you to the right patched version for your minor line. It's fine. I did mine by hand because I wanted to see the lockfile diff.

Then redeploy everything, including the apps I'd half forgotten about, because a forgotten demo is still a Node process with your environment variables in it. After that I went looking for signs that anything had got in first: access logs for odd POSTs to page routes carrying a Next-Action header from IPs I didn't recognise, and the containers themselves for processes or files that shouldn't be there. My containers run with a read-only filesystem and no capabilities, which doesn't stop RCE but does make life a lot less comfortable for whoever lands in one.

And finally I rotated secrets on anything that had been public and unpatched once the proof-of-concepts were out, because you can't prove nobody read process.env. For me that was a couple of database passwords and a webhook key. It's the step people skip, and it took less time than writing this paragraph.

Afterwards

Server functions feel like calling a function, but they're really a public POST endpoint with a clever serialisation format, and that format is now part of your attack surface in the same way JSON and multipart parsers always have been.

The managed platforms got WAF rules out quickly, which helped people on Vercel and Cloudflare. When you self-host nobody does that for you, and your real defence is how quickly you can go from advisory to patched build. For me that's one deploy script per app, and this week I was very glad of it. I'll write separately about how this has changed the way I write server actions.

Update (12 December 2025): there's a second round. People looking at the patch found two more problems in the same code: CVE-2025-55184, a denial of service where a crafted request can hang the server in an infinite loop, and CVE-2025-55183, where a request can get a server function's source code back. Neither is RCE, but the second one leaks anything hardcoded in a server function. The first DoS fix also turned out to be incomplete (CVE-2025-67779), so the versions to be on now are React 19.0.3, 19.1.4 or 19.2.3, and Next.js 16.0.10 or the latest patch of your 15.x line. If you patched on the 4th, you need to patch again.

First published on my blog. Cover photo: Decreasing volume, CC BY-SA 4.0, via Wikimedia Commons (source).

Start with the codemod:

npx @next/codemod@canary upgrade latest

It bumps next, react and react-dom and runs the transforms it knows about, which turned out to be more than I expected. It renamed my middleware, made most params access async and moved a few config keys around. Where it wasn't sure, it left a // TODO comment instead of guessing, which I was grateful for. I committed straight after it ran and before touching anything by hand, so my own changes would be a separate diff I could actually read.

middleware.ts becomes proxy.ts

The file is renamed and so is the function it exports:

- // middleware.ts
- export function middleware(request: NextRequest) {
+ // proxy.ts
+ export function proxy(request: NextRequest) {
    const session = request.cookies.get("session");
    if (!session && request.nextUrl.pathname.startsWith("/app")) {
      return NextResponse.redirect(new URL("/login", request.url));
    }
  }

I think the new name is more honest about what the file is for. Since the middleware bypass in March, the Next team has been fairly clear that this layer is for redirects, rewrites and headers at the edge of your app, and shouldn't be your only auth check. proxy.ts runs on the Node.js runtime. middleware.ts still works for now but is deprecated, so you might as well rename it while you're in there. My redirect stayed, but the real check already lives next to the query in the data layer. If yours doesn't, this is as good an excuse as any.

Turbopack builds

next dev and next build both use Turbopack by default now. I'd been on it for dev since 15, so the new part was the production build, which was clearly quicker on my machine (one small app and a couple of runs, so don't take that as a benchmark).

One thing broke. I had a custom webpack() function in next.config.ts adding an SVG loader, and with Turbopack as the default the build now fails when it finds a webpack config rather than silently ignoring it. Moving it across was easy enough:

  const nextConfig: NextConfig = {
-   webpack(config) {
-     config.module.rules.push({ test: /\.svg$/, use: ["@svgr/webpack"] });
-     return config;
-   },
+   turbopack: {
+     rules: {
+       "*.svg": { loaders: ["@svgr/webpack"], as: "*.js" },
+     },
+   },
  };

If you're not ready for that, next build --webpack still works.

Async params, for real this time

In 15, params and searchParams became promises but synchronous access still worked with a warning. In 16 the fallback has gone. The codemod handled the obvious pages and missed a couple of helper functions that took params as an argument, which the type checker found for me:

- export default function Page({ params }: { params: { id: string } }) {
-   const report = getReport(params.id);
+ export default async function Page({ params }: PageProps<"/reports/[id]">) {
+   const { id } = await params;
+   const report = await getReport(id);

PageProps<"/reports/[id]"> is a global type that gets generated (after next dev or next typegen) and is typed from the route itself, so I'm no longer hand-writing { params: Promise<{ id: string }> } and getting it slightly wrong. The same goes for cookies(), headers() and draftMode(). Await them.

Cache Components

This is the big conceptual change, and where most of my day went. You switch it on in config:

const nextConfig: NextConfig = {
  cacheComponents: true,
};

With it on, nothing is cached unless you ask. Pages are dynamic by default, and you opt particular functions or components into caching with the "use cache" directive. It's more or less Partial Prerendering grown up: a static shell, with the dynamic parts streaming in behind <Suspense>.

I'd been fighting the old implicit caching rules for about a year (fetch cached here but not there, revalidate = 0 sprinkled around until things behaved), so this was the change I actually wanted. My reports list ended up like this:

async function getRecentReports() {
  "use cache";
  cacheLife("minutes");
  cacheTag("reports");
  return db.report.findMany({ orderBy: { createdAt: "desc" }, take: 20 });
}

When someone creates a report, the server action calls updateTag("reports") so they see their new row straight away. There's also revalidateTag, which now wants a cache-life profile as its second argument, for the stale-while-revalidate kind of refresh where a slightly old value is fine.

The slow part wasn't writing that. It was that turning Cache Components on surfaced every place where I read cookies deep inside a component with no Suspense boundary above it, and there were more of those than I'd have guessed. The error messages do point at the right component, which helped a lot.

React Compiler, and deleting useMemo

React Compiler reached 1.0 earlier this month and Next 16 supports it as a stable option:

const nextConfig: NextConfig = {
  reactCompiler: true,
};

You need babel-plugin-react-compiler installed too, and builds are a little slower with it on because it goes through Babel. Then came the satisfying bit. I searched for useMemo and useCallback and removed the ones that only existed to keep references stable:

- const filtered = useMemo(
-   () => rows.filter((r) => r.status === status),
-   [rows, status],
- );
- const onSelect = useCallback((id: string) => setSelected(id), []);
+ const filtered = rows.filter((r) => r.status === status);
+ const onSelect = (id: string) => setSelected(id);

That was most of them. I kept a couple where the work really is expensive, mainly so the intent stays visible to whoever reads it next. React DevTools puts a "Memo" badge on components the compiler has optimised, which is how I checked it was doing anything at all. And if a component breaks the rules of React (mutating props, reading refs during render) the compiler just skips it, and the ESLint plugin tells you where. That list was useful on its own.

Two things from React 19.2

Next 16 ships with React 19.2, and I used two of its additions straight away. <Activity> hides part of the tree without unmounting it. I've got a tabbed filter panel that used to lose its state whenever you switched tabs:

<Activity mode={tab === "filters" ? "visible" : "hidden"}>
  <FiltersPanel />
</Activity>

Hidden content keeps its state and has its effects cleaned up while it's hidden, which is what I'd been faking with display: none, minus the effects carrying on in the background.

And useEffectEvent fixed an effect that reconnected a websocket every time the theme changed, because the theme was used inside the message handler:

const onMessage = useEffectEvent((msg: Message) => {
  showToast(msg, theme);
});

useEffect(() => {
  const ws = connect(roomId, onMessage);
  return () => ws.close();
}, [roomId]);

The handler always sees the latest theme, the effect only depends on roomId, and the lint rule knows not to ask for onMessage in the dependency list.

A few smaller things to finish. next lint has gone, so I run ESLint directly. Node 20.9 is now the minimum. Some next/image defaults changed, and if you use local images with query strings you'll need images.localPatterns.

The app builds faster, the caching is finally something I could explain to someone else without a diagram, and there are far fewer hooks in it than there were on Friday.

First published on my blog. Cover photo: OathOn, CC0, via Wikimedia Commons (source).

But as of July that's mostly over. Type stripping landed behind --experimental-strip-types in Node 22.6, was unflagged in Node 23.6 in January, and got backported to the LTS line in 22.18. On a current 22.x or on 24, this just works:

node scripts/rename-exports.ts

You get an ExperimentalWarning the first time, which I ignore for scripts. It's worth knowing what Node is doing, because it isn't type-checking anything. It swaps the type annotations for whitespace (so line and column numbers stay put and stack traces are right without source maps) and runs what's left. Which means only syntax that can be erased works. Enums, namespaces with runtime code, parameter properties like constructor(private db: Db) and old-style decorators all throw ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX. There's --experimental-transform-types for those, but I'd rather change the code, and enums were the only ones I actually had:

// before
export enum Status { Draft = "draft", Live = "live" }

// after
export const Status = { Draft: "draft", Live: "live" } as const;
export type Status = (typeof Status)[keyof typeof Status];

Call sites stay as Status.Live. Imports caught me out twice, though. A type-only import has to say import type, or Node keeps the import and then falls over at runtime when there's nothing there. And you write the real file extension, ./read.ts, which TypeScript used to hate. allowImportingTsExtensions fixes that when you're not emitting, or rewriteRelativeImportExtensions (TS 5.7) if you also compile with tsc.

The tsconfig I use for scripts

TypeScript 5.8 added erasableSyntaxOnly, which makes the checker complain about exactly the things Node can't strip, so you find out in the editor instead of at runtime. With verbatimModuleSyntax forcing the import type habit, the pair catches nearly everything:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "noEmit": true,
    "allowImportingTsExtensions": true,
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["scripts/**/*.ts"]
}

A trimmed-down script from one of my side projects, with top-level await, built-in fetch and no dependencies at all:

// scripts/check-links.ts
import { readFile } from "node:fs/promises";
import type { Post } from "../lib/types.ts";

const posts: Post[] = JSON.parse(await readFile("data/posts.json", "utf8"));

for (const post of posts) {
  const res = await fetch(post.url, { method: "HEAD" });
  if (!res.ok) console.log(`${res.status}  ${post.slug}`);
}

Also worth knowing: require() of ES modules is unflagged in 22.12 and 20.19, as long as the module doesn't use top-level await. I had an old internal tool pinned to an old version of a library for exactly that reason, and bumping it just worked.

I haven't uninstalled tsx. Anything that runs in production still goes through a proper build with a type-check in CI, and Node doesn't read paths from tsconfig, so code importing @/lib/db needs a loader (or package.json imports like #lib/db, which I've started moving to). Stripping also never checks your types, so tsc --noEmit stays in CI. Node running the file only tells you it parses.

For scripts, seed files and one-off migrations, though, I just run the .ts file now. Not having to explain to a new joiner why they need three packages to run seed.ts is a small thing that I'm very happy about.

First published on my blog. Cover photo: Peter Shanks from Hobart, Australia, CC BY 2.0, via Wikimedia Commons (source).

Claude Code went generally available on 22 May along with Claude 4 (Opus 4 and Sonnet 4). I'd played with the research preview earlier in the year on 3.7 Sonnet and liked it, but it felt like a demo. With Claude 4, and with it then being included in the Pro and Max plans, it went from interesting to the first thing I open in the morning.

Handing over the steps

Before, I wrote the code and AI either guessed the next line or answered whatever I pasted into a chat. Now I describe a task and something else does the steps. It runs in the terminal, inside the repo, reads the files it thinks matter, greps for usages, edits, runs npm test or go test ./..., reads the failure and tries again. Sometimes I watch, sometimes I make a coffee. My part of the loop has shifted from typing to reviewing, and I read a lot more code than I write.

A recent example from work: a component library had the same sorting logic copied into several places around a Table. I asked for it to be pulled into a hook, with the call sites updated, the existing tests kept green and new tests for the hook. It took a few minutes and touched a handful of files, and reviewing took me longer than the work did. By hand that's a morning.

What made it useful on our codebase, as opposed to just impressive, was a CLAUDE.md file at the root, which it reads at the start of every session. Mine is things like this:

# Notes for Claude

- Package manager is pnpm. Never npm.
- Run `pnpm test --filter <pkg>` for one package, not the whole repo.
- UI components live in packages/ui. Don't create new ones in apps/.
- We use date-fns, not moment. Don't add dependencies without asking.
- Go services: handlers stay thin, logic goes in internal/<domain>.

Pretty much every line is a mistake it made once. It's the onboarding doc I'd give a new joiner, minus the history, and I keep it short because when it got long the important lines started getting ignored.

The bigger use at work has been moving some old Java services to Go. They do fairly simple things (read files, validate, transform, push to an API) wrapped in a lot of ceremony. What works is pointing it at one class and its tests and asking for the behaviour as a list of rules, edge cases included. I check that list against what I know and against production logs, and only then ask for a Go version with table-driven tests for each rule. What doesn't work is "convert this package to Go". It'll do it, and it'll compile, and it may well drop the one null check that was the whole reason an old bug never came back.

The new ways it goes wrong

The failures are different from chat, and a bit worse, because the output is bigger.

It's very comfortable with big diffs. Ask for one change and you can get renamed variables, a reshuffled import block and a "small improvement" to some unrelated function, all summarised as a tidy-up. Each bit is harmless, but together they bury the one change that matters, so "only touch what this task needs" now goes into nearly every prompt. A couple of times it has fixed a failing test by changing what the test expected instead of fixing the code, and the summary said all tests pass, which was technically true. I read test diffs first now.

It also gets stuck sometimes, trying the same broken idea in slightly different clothes. When I see the third similar attempt I stop it and point it somewhere else, because letting it loop has never once been quicker. And it doesn't know about the parts of our setup that aren't in the repo: environment variables that only exist in CI, a service that needs to be running locally, a feature flag. It writes code that works in its world.

So a few habits have changed. I write tasks like tickets (what, why, which files, what done looks like, what to leave alone), and the better the ticket, the less there is to review. I make sure the working tree is clean before anything big, so git diff shows only its work and git checkout . is a cheap undo. And I do the interesting bits myself. It writes the hook, but I decide whether there should be a hook, partly because that's where I learn and partly because that's where it's most likely to pick something generic.

The habit I worry about is skimming. Reviewing tires you out in a different way from writing, and I've caught myself approving a diff because the summary sounded right. I've gone back to the rule from February: if I can't explain a change without reading the summary, it doesn't get committed.

On refactors and rewrites with decent tests, it saves me a lot more time than in February. On work where the hard part is deciding what to build, not much has changed, because that part is still mine. It's all moving every couple of weeks at the moment (hooks have just landed, and subagents are apparently next), so I'll come back to this once it's stopped being new.

First published on my blog. Cover photo: Anirban Saha, CC BY-SA 4.0, via Wikimedia Commons (source).

I've had a few weeks to poke at the preview on my own projects, and the speed-up on a full type-check is real. It isn't a clean 10x on a codebase my size, but it's big enough that I stopped looking at the decimals. Trying it takes two commands:

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

What I actually care about more is the editor, though. Most of my day isn't spent running tsc. It's hovering, jumping to definitions, and waiting for the red squiggles to catch up after I rename something in a shared types file, and on the big monorepo at work the language service can take long enough to load that I've gone and made tea. If the editor numbers Microsoft quoted hold up on our repo, that changes how the job feels far more than shaving CI minutes does. (Builds of the app itself won't move much, by the way. Most of us already strip types with esbuild, swc or Turbopack and never use tsc to emit anything.)

People were cross about Go instead of Rust within the hour. The team's reasoning is that this is a port and not a rewrite: they want to move the existing compiler across file by file and keep its structure, so it behaves the same way, and the checker leans heavily on garbage collection and on data structures that point back at each other. Go is happy with both. I write Go most weeks for backend services and that matched my gut, because ported Go tends to read a lot like the code it came from, and someone who knows the old checker should be able to find their way around the new one. Go also gives them cheap shared-memory parallelism, which is a chunk of where the speed comes from.

The thing I'd watch is everything that imports typescript as a library. ts-morph, typescript-eslint's type-aware rules, custom transformers, a lot of codegen, Angular's and Vue's tooling all talk to the compiler's JavaScript API, and you can't require a Go binary. A new API is apparently in the works, but it won't be the same one. Language service plugins in tsconfig are in the same boat, and I've got one on an older project that I'm not at all sure survives.

For now I've added a second script to my side projects so I can compare the two:

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "typecheck:native": "tsgo --noEmit"
  }
}

At work I made a list of everything in our toolchain that imports typescript directly. It was longer than I expected, and I think that list is the real migration, more than the compiler swap itself. Issues go to microsoft/typescript-go if you hit something odd.

First published on my blog. Cover photo: Cephas, CC BY-SA 3.0, via Wikimedia Commons (source).

What the bug was

Middleware runs before a request reaches your page or route handler, which is why so many of us put "no session cookie, redirect to /login" there. One file, every route covered.

Internally, Next.js has to stop middleware from calling itself in a loop, so it tags its own internal requests with a header, x-middleware-subrequest, and skips middleware when it sees it. The trouble was that nothing checked where that header came from. Anyone could send it, the server would treat the request as one of its own, and middleware simply didn't run. If middleware was your only auth check, the check was gone (along with anything else you did there, like CSP headers or a maintenance-page rewrite).

It's CVE-2025-29927, advisory GHSA-f82v-jwr5-mffw, disclosed on 21 March 2025. Self-hosted apps running next start or the standalone server were exposed, which is exactly how I run things in Docker at home. Vercel and Netlify weren't, and static exports have no middleware to skip. The fixes are 15.2.3, 14.2.25, 13.5.9 and 12.3.5.

Testing my own apps

The value the header needs depends on the version. Older releases want the middleware's name (middleware, or src/middleware if you use a src/ folder). Newer ones count recursion depth and give up after five, so the value is the name repeated five times with colons. I only tried this against apps I own, from my own machine:

curl -s -o /dev/null -w '%{http_code}\n' https://myapp.example.com/dashboard
# 307, off to /login as expected

curl -s -o /dev/null -w '%{http_code}\n' \
  -H 'x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware' \
  https://myapp.example.com/dashboard
# 200

That 200 was not a fun thing to see. An internal tool on 15.1 rendered its dashboard with no session at all. Its data didn't load, because the API behind it checked the token itself, but the page shell came back with nav items and labels that had no business being public. On an older 14.x side project the src/middleware form was the one that worked, so try both if you're checking.

Patching was dull, which is how you want it:

npm install next@15.2.3
npm ls next   # make sure nothing else is pulling in an older copy
docker build --no-cache -t myapp:latest .

I built without cache because I didn't want to find out on Monday that a layer was still holding the old node_modules. After the redeploy, the same curl gave a 307. My apps sit behind a reverse proxy, so I also strip the header there; there's no reason a request from outside should ever carry an internal framework header, patch or no patch:

location / {
    proxy_set_header x-middleware-subrequest "";
    proxy_pass http://127.0.0.1:3000;
}

An empty value in nginx means the header isn't forwarded at all. On Cloudflare, a transform rule that removes the request header does the same thing at the edge.

Where the auth should have been

The patch was the easy bit. The uncomfortable bit was the shape of the internal tool. Middleware read the cookie, verified the session and redirected, and the page simply assumed that if it was rendering, the user must be allowed:

// middleware.ts
export async function middleware(req: NextRequest) {
  const session = await getSession(req);
  if (!session) {
    return NextResponse.redirect(new URL("/login", req.url));
  }
}

export const config = { matcher: ["/dashboard/:path*"] };

// app/dashboard/page.tsx
export default async function Dashboard() {
  const reports = await db.report.findMany(); // nobody asks who is asking
  return <ReportList reports={reports} />;
}

Plenty of tutorials teach exactly this, and it means one framework bug becomes an auth bypass. Now the page asks who the user is, and the query is scoped to them:

// lib/auth.ts
import "server-only";

export async function requireUser() {
  const session = await getSession();
  if (!session) redirect("/login");
  return session.user;
}

// app/dashboard/page.tsx
export default async function Dashboard() {
  const user = await requireUser();
  const reports = await db.report.findMany({ where: { orgId: user.orgId } });
  return <ReportList reports={reports} />;
}

Middleware still does the redirect, since it's nicer for people to bounce to login before anything renders, but it's a convenience now. The lock sits next to the data.

The API that saved me is written in Go, and every handler checks the token because there's no magic file in Go that runs first. Slightly funny that the more boring stack had the safer habit.

If you're still on an old version, upgrade to the patched release for your line. If you really can't this week, strip x-middleware-subrequest at your proxy or CDN today, then go through anything that relies on middleware for auth and add a check in the page, route handler or server action itself.

First published on my blog. Cover photo: ImagePerson, CC BY-SA 4.0, via Wikimedia Commons (source).

For context, I'm a front-end-heavy full stack dev. Most days are React and TypeScript, with some Go and some older code at work that nobody is keen to touch.

What I'm using

Copilot has been on in VS Code for over a year, doing autocomplete. I barely notice it any more, which I suppose is the point. I've also been using Cursor on and off, and its tab completion is better than Copilot's because it guesses the next edit, not just the next line: rename a prop in one place and it offers to fix the next three usages. I still can't decide how I feel about working in a fork of VS Code.

And then there's chat in a browser tab, mostly Claude 3.5 Sonnet and sometimes ChatGPT. That's where the bigger jobs happen, in a loop I suspect a lot of people will recognise. Copy code in, explain the problem, copy the answer out, paste, run, copy the error back in. It's clunky. The model can't see my repo, so I'm the one deciding which files matter and pasting them across, and choosing that context is half the skill.

Where it earns its keep

Tests, by a distance. I paste a component, ask for Testing Library tests covering the empty, loading and error states, and what comes back is mostly right. I would have written those tests anyway, just slowly, and on a Friday afternoon I might have quietly skipped the error state.

It's also good at regex and one-off parsing. Recently I needed meter IDs out of a messy CSV where some rows were quoted and some weren't, and a description plus a quick test on twenty lines got me there far faster than half an hour on regex101. Same with boilerplate: a Zod schema from a JSON sample, a typed fetch wrapper, the fifth form in an app that already has four.

The one I didn't expect is translating between frameworks. I spent a few years on Vue and Nuxt before React and still have Vue snippets lying around. Paste a single-file component and ask for a React function component, and it maps v-model to controlled inputs, computed to useMemo and watch to useEffect reasonably well. I tidy it afterwards, but the shape is right. It's a decent first reader for old code too. At work there's legacy Java nobody has opened in years, and asking what a long class does and what would break if I changed a method gives me a rough map I can then check.

Where it costs me

Made-up APIs are rare but expensive, because they look right. I once got revalidate: "on-demand" passed into fetch in a Next.js app. That isn't a thing. It compiled (the types were loose enough), it ran, and it did nothing at all, and I lost a good twenty minutes wondering why my cache wouldn't clear.

Stale Next.js knowledge is the constant one. The models have seen far more Pages Router code than App Router, so getServerSideProps turns up in projects with an app/ folder. Next 15 made cookies() and headers() async, and as far as I can tell most models don't know yet, so I've started opening every chat with "Next.js 15, App Router".

Long chats drift as well. Thirty messages in, it forgets the constraint I gave at the start (no new dependencies) or puts back a bug I already fixed. I start fresh chats a lot and paste a short summary at the top, which works but is all manual. And with React state bugs, stale closures, effects firing twice in Strict Mode, it tends to fix the symptom. I mostly use it as a rubber duck there: I ask it to walk through the render order, and I usually spot the problem myself while reading.

The bigger cost is quieter. When I write code myself I know why each line is there, and when I paste sixty lines from a chat I only know it passed the one thing I tried. So I've got a rule that if I can't explain a pasted block to a colleague without looking at it, it doesn't get committed. That eats into the time saved, possibly quite a lot of it.

Overall, on a normal feature it saves me a fair chunk of time, mainly on tests and boilerplate. On a bug in code I don't know, it's roughly break-even. On anything to do with Next.js caching or brand-new APIs it can be worse than nothing. Nowhere near 80%, but a fair chunk every day still adds up.

What I keep wishing for is something that can read the repo and run the tests itself, so I'm not the clipboard in the middle. Cursor's agent mode is heading that way and I keep hearing about tools that live in the terminal. I'll write a follow-up if one of them actually changes how I work.

First published on my blog. Cover photo: Markus Spiske markusspiske, CC0, via Wikimedia Commons (source).