DEV Community: Ganesh Joshi

Core Web Vitals When Your Hero Section Is an AI Chat

Ganesh Joshi — Sun, 08 Nov 2026 15:45:29 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Putting a live AI chat at the top of a landing page is a good demo and a bad hero. Every property that makes it compelling, that it is interactive, that it streams, that it responds to what you type, is also a property that Core Web Vitals penalises. The chat is usually the largest element on screen, so it becomes the LCP element. It grows as tokens arrive, so it moves everything under it. And it is the first thing a visitor touches, so it owns your INP.

None of that is unavoidable. It just means the hero has to be designed backwards from the metric.

The chat should not be your LCP element

LCP measures when the largest block of content in the viewport finishes rendering. If that block is a chat transcript that appears after hydration, your LCP cannot happen until JavaScript has downloaded, parsed, and run. On a mid-range phone over slow 4G that is several seconds you do not control.

The fix is to make something else the largest element, and to make that thing static.

In practice this means the hero is a headline, a subhead, and a chat panel that is present but visually secondary. Render the headline server-side as real text. Text has no decode step, no network request beyond the HTML itself, and it is eligible to be the LCP element the moment the document paints.

// The h1 is the LCP candidate. It ships in the HTML and needs no JS.
<section className="hero">
  <h1>Ask anything about your codebase</h1>
  <p>Answers grounded in your own repository, not the public internet.</p>
  <ChatPanel />
</section>

If the design genuinely requires the chat to dominate the fold, then pre-render its first state on the server: a greeting message, a couple of example prompts, the input box. That markup is real content, it counts for LCP, and it arrives with the document.

Reserve the space before the tokens arrive

Streaming output is the most reliable way to generate layout shift. Each chunk makes the transcript taller, and everything below it moves down. That is textbook CLS, and unlike LCP it keeps accumulating for as long as the response runs.

Give the transcript a fixed height, or a min-height large enough for a typical answer, and let it scroll internally:

.chat-transcript {
  min-height: 22rem;      /* space is reserved before the first token */
  overflow-y: auto;
  overscroll-behavior: contain;
}

Two related mistakes are worth naming because they look harmless.

The first is animating the container open as the response starts. Transitioning height or width recalculates layout on every frame and shifts whatever sits below. If you want the panel to feel like it is opening, animate transform instead. transform and opacity are the only two properties the compositor can handle without touching layout.

The second is the typing indicator. A three-dot bubble that is inserted, then removed, then replaced by the answer causes two shifts on its own. Render it inside the space you already reserved, and swap its contents rather than its box.

INP belongs to the input box, not the model

INP measures the delay between an interaction and the next frame the browser paints. It does not measure how long your model takes to answer. This distinction is worth internalising, because it means a slow model does not have to mean a bad INP score.

What ruins INP is doing work on the main thread inside the event handler. Tokenising the prompt, building embeddings client-side, or serialising a large conversation history before the request goes out all block the frame.

Keep the handler to the minimum that produces visible feedback:

function onSubmit(text: string) {
  // Paint first: echo the user's message and clear the input.
  appendMessage({ role: 'user', text });
  setInput('');

  // Everything expensive happens after, off the interaction's critical path.
  void sendToModel(text);
}

The user sees their message appear immediately. The request, the streaming, and the rendering of the reply all happen afterwards, and none of it is attributed to that interaction.

Watch TTFB if the route is server-rendered

If the page server-renders anything that depends on a model or a vector database, that work sits in front of your TTFB, and TTFB is inside LCP. A route that waits 400ms on a similarity search before it can send a byte has spent 400ms of an LCP budget that is roughly 2.5 seconds on mobile.

The hero almost never needs that data. Render the shell immediately and let the dynamic part stream in or load client-side. In frameworks with streaming SSR, put the model-dependent region inside a boundary so the rest of the document flushes without waiting for it.

Measure in the field, not on your laptop

Lab tools are useful for finding causes and useless for judging severity. Your development machine has a fast CPU, a warm cache, and a local server, which is the combination least likely to reproduce what a phone on a train experiences.

Two habits are worth building:

Habit	Why it matters
Read field data, not lab scores	LCP and CLS are scored at the 75th percentile of real visits
Confirm which element is actually LCP	It is often not the one you assumed, and optimising the wrong element wastes the work

The second one catches more mistakes than any other check. You can log it directly:

new PerformanceObserver((list) => {
  const entry = list.getEntries().at(-1);
  console.log('LCP element:', entry.element, Math.round(entry.startTime), 'ms');
}).observe({ type: 'largest-contentful-paint', buffered: true });

Run that on the deployed site, on a throttled connection, and see what it names. If it points at your chat transcript, the rest of this post is the work list. If it points at the headline, the hero is already shaped correctly and your budget is going somewhere else.

The short version

An AI chat hero is worth building. It just cannot be the thing the browser is waiting on. Make static text the largest element, reserve the transcript's space before the first token lands, keep the submit handler down to visible feedback, and stream anything the model touches instead of blocking the document on it. The demo stays impressive and the metrics stop paying for it.

React error #418: five hydration bugs I shipped

Ganesh Joshi — Sun, 01 Nov 2026 15:43:35 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

If your production console shows Minified React error #418, React is telling you that the HTML the server sent and the first render in the browser did not match. The development build spells it out ("Hydration failed because the server rendered HTML didn't match the client") and shows a diff. The production build gives you a number and a link to react.dev/errors/418.

It is easy to treat it as console noise, because the page still works. It is not free. When hydration fails, React throws away the server-rendered tree and renders the whole root again in the browser. On my site that one error took mobile Total Blocking Time from 0 to 420 ms and the Lighthouse performance score from 96 to 83, and pushed Largest Contentful Paint 1.2 seconds past First Contentful Paint, which had always been equal.

I have shipped this error five different ways on one Next.js site. Here is each one, how it was found, and the fix that stuck.

1. Randomness or time in a `useState` initializer

The games on the site generate a puzzle, a word or a board. The obvious code seeds state when the component is created:

// Wrong: the initializer runs on the server and again in the browser.
const [puzzle, setPuzzle] = useState(() => generatePuzzle());

The initializer runs twice, once during prerendering and once during hydration, and Math.random() gives a different answer each time. The same thing happened in a lorem ipsum generator, a mock data generator and a password generator. Anything that reads Date.now() or new Date() while rendering has the same problem.

The fix is a deterministic first value, with the random one set after mount:

const [puzzle, setPuzzle] = useState(INITIAL_PUZZLE); // fixed, the same everywhere
useEffect(() => {
  setPuzzle(generatePuzzle()); // runs only in the browser, after hydration
}, []);

The first frame shows the fixed puzzle for an instant. For a game that is fine. For anything where the flash matters, render a placeholder of the same size until the effect runs.

2. Formatting with the machine's locale

// Wrong
<span>{downloads.toLocaleString()}</span>
<time>{new Date(post.date).toLocaleDateString()}</time>

With no locale argument, toLocaleString() uses whatever the current machine prefers. The server that prerenders the page (on Vercel, en-US in UTC) and a visitor in Germany or India produce different strings, so the text differs and hydration fails. It never reproduces on your own machine if your machine matches the server.

Pass the locale you rendered with, or move the formatting after mount:

<span>{downloads.toLocaleString('en-US')}</span>

To catch this class of bug, load the deployed page in a browser with a different locale and time zone. In Playwright that is two options on the context:

const context = await browser.newContext({ locale: 'de-DE', timezoneId: 'America/Los_Angeles' });

3. Browser-only APIs while rendering

Five tools on the site called something during render that only exists, or only behaves the same, in a browser: DOMParser in an XPath evaluator, document in an SVG animation tool and an HTML-to-Pug converter, and URL.createObjectURL in an SVG viewer. That last one is a good example of why this can hide: on the server it produced nothing useful, in the browser it produced a blob: URL, and the visible symptom was a broken image, not an error.

// Wrong: runs during render on the server too.
const src = URL.createObjectURL(new Blob([svg], { type: 'image/svg+xml' }));

The fix is to compute these only after the component has mounted:

function useHasMounted() {
  const [mounted, setMounted] = useState(false);
  useEffect(() => setMounted(true), []);
  return mounted;
}

const mounted = useHasMounted();
const src = useMemo(
  () => (mounted ? URL.createObjectURL(new Blob([svg], { type: 'image/svg+xml' })) : null),
  [mounted, svg],
);

Remember to revoke the URL when nothing can reach it any more, but that is a separate bug.

4. `usePathname()` in a prerendered component

This is the one that cost the most, because I fixed it and then shipped it again.

The site's navigation highlights the current page. The highlight compared the path:

const pathname = usePathname();
const isActive = pathname === href;

On the deployed homepage this logged #418 on every visit. It never happened locally, with next dev or with a local production build. The comparison for the / link came out differently in Vercel's prerender of the index route than in the browser, so the active class differed between the server HTML and the first client render.

The first time, I fixed it in one header. Later a different navigation design carried the same comparison into a new component, and it went live again. That second time is the one that took Lighthouse from 96 to 83.

The fix that stuck is a shared hook that gates only the / comparison on mount and leaves every other link server-rendered, so the other routes keep their active state from the first paint. Simplified, it looks like this:

export function useIsRouteActive(href: string) {
  const pathname = usePathname();
  const mounted = useHasMounted();
  if (href === '/') return mounted && pathname === '/';
  return pathname === href || pathname.startsWith(`${href}/`);
}

The second part of the fix was making sure it could not come back. The repository has a small script that runs before every build and fails when a client component compares usePathname() directly. A lint rule would do the same job. Writing the lesson down had not been enough.

5. A script that edits `<body>` before React gets there

The site sets a colour scheme and, on festival days, a few data- attributes on <body> from an inline script, so the right look paints before any JavaScript bundle loads. React then hydrates <body>, finds attributes it did not render, and complains.

This is the one case where suppressHydrationWarning is the right tool:

<body suppressHydrationWarning>

It only silences attribute and text differences on that one element, not its children, which is exactly the scope you want. Two rules keep it honest: only the element the script edits gets it (here <body>, not <html>), and the script only ever sets attributes, never content.

suppressHydrationWarning is not a fix for the first four causes. Those are real differences in what renders, and hiding the warning leaves the re-render in place.

How to find yours

Read the console on the deployed site, not just locally. Three of these five never reproduced on my machine.
Run the development build once to get the readable message and the diff React prints, which names the element and the two values.
Load the page with a foreign locale and time zone. It finds cause 2 and anything else that reads the environment.
Search the codebase for Math.random, Date.now, new Date(, toLocale, window., document., DOMParser and usePathname inside components that render on the server.

The common thread is simple: everything a component renders the first time must be computable on the server, from the same inputs, with the same answer. Anything that depends on the browser, the clock, chance or the visitor waits until after mount.

Node Streams for Large RAG Uploads and Embedding Pipelines

Ganesh Joshi — Sun, 01 Nov 2026 15:43:33 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Most retrieval pipelines start the same way. Read the uploaded file, extract its text, split it into chunks, embed the chunks, write them to the database. Written with await readFile() at the top it is about fifteen lines, and it works perfectly until a customer uploads a document larger than the memory you have.

The problem is not just peak memory. It is that a single large upload can take down the process handling everyone else's, and that failures arrive after you have already spent money embedding half the file.

Where the memory actually goes

There are three places a naive pipeline buffers, and they compound:

const buf = await readFile(path);        // 1. whole file in memory
const text = await extractText(buf);     // 2. whole extracted text
const chunks = splitIntoChunks(text);    // 3. every chunk, at once
await Promise.all(chunks.map(embed));    // and every request in flight

A 400MB PDF can hold well over a gigabyte across those stages before a single embedding call returns. The final line is the worst of them: Promise.all over ten thousand chunks issues ten thousand concurrent HTTP requests, which will exhaust sockets, trip provider rate limits, and produce a rejection that discards all the successful work alongside the failed call.

Streams turn peak memory into steady memory

The stream version processes a window at a time, so memory tracks chunk size rather than file size:

import { pipeline } from 'node:stream/promises';
import { createReadStream } from 'node:fs';

await pipeline(
  createReadStream(path),
  extractTextStream(),      // Transform: bytes to text
  chunkStream({ size: 1000, overlap: 100 }),
  embedStream({ concurrency: 5 }),
  writeToDatabase()
);

Use pipeline from node:stream/promises rather than chaining .pipe(). It propagates errors through every stage and destroys the whole chain when one fails, which is the difference between a clean failure and a leaked file descriptor plus a half-written batch. Chained .pipe() calls do neither.

Backpressure is the part that matters

Backpressure is the mechanism that makes this work, and it is easy to accidentally disable.

When a writable stage cannot keep up, it stops accepting data, and that signal travels back up the chain until the file read pauses. Embedding is always the slowest stage in a RAG pipeline, by orders of magnitude: parsing is CPU-bound and fast, embedding is a network round trip. Backpressure is what stops the parser from racing ahead and queuing the entire document in front of the embedder.

You lose it the moment a stage buffers internally:

// Breaks backpressure: collects everything, then acts.
const all = [];
for await (const chunk of source) all.push(chunk);

// Preserves it: one item at a time, with await between.
for await (const chunk of source) {
  await handle(chunk);
}

The for await loop is the simplest correct consumer. It will not request the next chunk until the body has finished, so the upstream source stays paused while you work.

Batch the embedding calls

Embedding one chunk per request wastes most of the round trip. Every provider accepts arrays, and a batch of 50 to 100 costs roughly the same wall-clock time as a batch of one.

async function* batched(source, size = 64) {
  let batch = [];
  for await (const item of source) {
    batch.push(item);
    if (batch.length >= size) {
      yield batch;
      batch = [];
    }
  }
  if (batch.length) yield batch;  // the tail matters
}

for await (const batch of batched(chunks)) {
  const vectors = await embedMany(batch.map((c) => c.text));
  await db.insertMany(batch, vectors);
}

Forgetting the final partial batch is a common bug, and a quiet one: every document silently loses its last few dozen chunks, which usually includes the conclusion.

Insert as you go rather than accumulating vectors for a single write at the end. Embeddings are large, holding them all defeats the purpose of streaming, and incremental writes mean a failure at 80% keeps the first 80%.

Make it resumable, because it will fail

A long ingest will be interrupted. The process restarts, the network blips, the provider rate limits you. If a failure means starting over, you pay for every embedding twice.

Record progress alongside the data:

await db.insertMany(batch, vectors);
await db.updateJob(jobId, { lastChunkIndex: batch.at(-1).index });

On restart, skip to lastChunkIndex and continue. This ordering matters: write the chunks first, then the progress marker. If it crashes between the two you re-embed one batch, which is cheap. Reverse the order and a crash loses that batch entirely, with the job convinced it succeeded.

For rate limits specifically, retry the batch with exponential backoff rather than failing the job. A 429 is a request to wait, not an error condition.

Verify with the number that matters

The test for all of this is not whether it completes. It is whether memory stays flat.

setInterval(() => {
  const mb = process.memoryUsage().heapUsed / 1024 / 1024;
  console.log(`heap: ${Math.round(mb)}MB`);
}, 1000);

Run your largest realistic document through and watch. A correct streaming pipeline holds roughly steady regardless of file size. If the line climbs with the document, something in the chain is still buffering, and the profile will tell you which stage by where the climb begins.

That single graph is worth more than any amount of reasoning about the code, because every one of the mistakes above looks fine when you read it.

“Mindblowing” AI Results? Read the Paper or Model Card First

Ganesh Joshi — Sun, 01 Nov 2026 15:43:02 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

A striking benchmark number crosses your feed. The claim is usually accurate and the framing is usually wrong, because the number arrived without the conditions that produced it. Those conditions are in the paper, and reading for them takes about fifteen minutes.

This is a practical skill rather than an academic one. You do not need to evaluate the methodology like a reviewer. You need to work out whether the result applies to what you are building.

Read it out of order

Nobody has time to read papers linearly, and you do not need to. Four sections answer most questions:

Abstract, for the claim as the authors state it. Compare this to the claim as it reached you. The difference is often the entire story.

Limitations, which is where the caveats live and is the section least likely to survive summarisation. Many venues now require it, which is a gift to anyone reading quickly.

Experimental setup, for what was actually measured. This is where you find out that the evaluation used a specific subset, or allowed multiple attempts, or gave the model tools.

Results tables, including the baselines. A large improvement over a weak baseline is a different result from a small improvement over a strong one.

Introductions and related work are the least useful parts for this purpose. Skip them without guilt.

The questions that change what a number means

A few specifics account for most of the distance between a headline and reality:

How many attempts? A score where the model gets several tries and any success counts is not comparable to one where the first answer is the answer. Both are legitimate measurements of different things, and only one resembles a user typing a question once.

What was the model given? Tool access, retrieval, a scaffold that retries and self-corrects, or a carefully engineered prompt. All are reasonable in research and none are free in production.

Which subset? Evaluations often report on a filtered slice, sometimes for good reasons. The filtering criteria decide how much the number generalises.

Contamination? For benchmarks that predate the model's training data, some of the test set may have been in it. Good papers address this directly. Its absence is worth noticing.

Who is comparing? A lab reporting its own model against competitors chose the evaluation conditions. That is not dishonest, and it is not neutral either.

Model cards deserve more attention than papers

For anything you are considering using, the model card or system card is usually the higher-value read. It is written by the people who built the thing, it states intended use and known weaknesses, and it tends to be blunter about limitations than a launch post.

It is also where you find the operational facts that determine whether you can build on it: context limits, supported modalities, safety behaviour, and the conditions under which performance degrades.

The pattern worth internalising is that the marketing post and the model card describe the same system with very different emphases, and the second one is the one written for you.

Wait for someone else to try it

The strongest signal on a surprising result arrives weeks later, when independent groups attempt to reproduce it. Reproductions get a fraction of the attention of the original and carry considerably more information.

There is usually no cost to waiting. If a technique genuinely works, it will still work in a month, and by then you will know whether it survives contact with someone who did not have an interest in the outcome.

What this looks like in practice

You do not need to do this for everything. Match the effort to the decision.

Situation	Effort
Curiosity	Read the abstract, move on
Might affect a roadmap decision	Abstract, limitations, setup
Planning to build on it	The above, plus the model card and any reproductions
Citing it to convince someone	Read it properly, including baselines

That last row is the one worth being strict about. Repeating a number you have not verified attaches your credibility to someone else's summary, and when it turns out the evaluation allowed ten attempts, it is your recommendation that was wrong.

None of this requires cynicism. Real progress happens constantly and is worth being excited about. It just means the excitement should come after the fifteen minutes rather than before, and that you can say where a claim came from when somebody asks.

CSP and Third-Party AI Widgets: Copilot, Chat, and Scripts

Ganesh Joshi — Sun, 01 Nov 2026 15:43:01 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Adding a vendor's AI chat widget is a two-line change to your HTML and a much larger change to your security posture. The script runs with the same privileges as your own code: it can read the DOM, read localStorage, and make requests as the logged-in user.

Content Security Policy is how you bound that. The catch is that most widget install guides ask you to weaken exactly the directives that were doing the work.

The install instructions are the problem

Vendor docs commonly suggest one of these:

script-src 'self' 'unsafe-inline' 'unsafe-eval' https://widget.vendor.com;

Each addition removes a specific protection. 'unsafe-inline' allows any injected <script> tag to execute, which is the primary thing CSP exists to prevent. 'unsafe-eval' allows strings to be compiled into code, re-opening a class of injection that is otherwise dead. A wildcard host allows anything the vendor ever hosts, including a compromised subdomain.

You can usually avoid all three. Treat the vendor's snippet as a starting point to be narrowed, not a requirement.

Nonces instead of unsafe-inline

If the widget needs an inline bootstrap, give that specific script a nonce rather than allowing every inline script on the page:

// middleware.ts
const nonce = crypto.randomUUID();
const csp = [
  `script-src 'self' 'nonce-${nonce}' https://widget.vendor.com`,
  `connect-src 'self' https://api.vendor.com`,
  `frame-src https://widget.vendor.com`,
  `img-src 'self' data: https://cdn.vendor.com`,
  `style-src 'self' 'nonce-${nonce}'`,
  `object-src 'none'`,
  `base-uri 'self'`,
].join('; ');

A nonce is generated per response and must therefore come from a dynamically rendered layer. That is a real constraint: a fully static page cannot carry a per-request nonce, so on prerendered routes you are choosing between hashes and moving the widget behind an iframe.

Hashes work when the inline content is fixed. Compute the SHA-256 of the script body and allowlist that digest. It breaks the moment the vendor changes a byte, which is either a maintenance burden or an early warning, depending on your temperament.

Know which directive each behaviour needs

Widgets fail in confusing ways when one directive is missing, because the browser blocks silently from the page's perspective:

Directive	Governs	Missing it looks like
`script-src`	Loading the widget bundle	Nothing renders at all
`connect-src`	Its API calls and WebSockets	Widget appears, never responds
`frame-src`	Widgets that render in an iframe	Empty box where the panel should be
`img-src`	Avatars, logos, uploaded images	Broken images inside the widget
`style-src`	Injected stylesheets	Unstyled widget, correct behaviour

The second row causes the most support tickets. The panel opens, the user types, and nothing comes back, because connect-src is blocking the API host while script-src allows the bundle. The two are frequently different domains.

Roll it out in report-only first

Never enforce a new policy blind. Content-Security-Policy-Report-Only applies the rules, reports what would have been blocked, and blocks nothing:

Content-Security-Policy-Report-Only: script-src 'self' https://widget.vendor.com; report-uri /api/csp-report

Run it for long enough to cover real traffic, including the paths where the widget behaves differently. Then read the reports, add the origins you genuinely need, and only afterwards switch the header name to enforce.

Expect noise. Browser extensions inject scripts into your pages and generate violations you cannot fix and should not act on. Filter reports by whether the blocked URI is something you recognise before treating any of it as a signal.

A widget you cannot trust belongs in an iframe

CSP limits where code comes from. It does not limit what that code does once it is running in your page.

If the widget handles anything sensitive, or if you simply do not want a third party reading your DOM, put it in an iframe on a different origin. The browser's same-origin policy then does the isolation that CSP cannot: the widget cannot read your cookies, your localStorage, or the contents of the page around it. Communication goes through postMessage, where you control exactly what crosses the boundary.

window.addEventListener('message', (event) => {
  if (event.origin !== 'https://widget.vendor.com') return;  // check first
  handle(event.data);
});

That origin check is not optional. Without it any page that can reach your frame can send it messages, and the handler will process them.

Test it on the built site, not in development

This is the part most teams get wrong. Development servers routinely relax CSP because bundler tooling needs 'unsafe-eval' for hot reloading. Which means development cannot tell you whether production will work.

Verify against a production build, and listen for violations directly rather than reading the console by eye:

document.addEventListener('securitypolicyviolation', (e) =>
  console.log(e.violatedDirective, e.blockedURI)
);

That event fires even when the failure is swallowed by a try/catch inside the widget, which is common. A vendor bundle that catches its own network errors and renders an empty state gives you no console error at all, and that event is the only thing that tells you the policy was the cause.

The shape of a good outcome

You should end with a policy that names every vendor origin explicitly, has no wildcards, no 'unsafe-eval', and no blanket 'unsafe-inline'. It should be verified against a production build with a violation listener attached, and anything you genuinely cannot constrain should be sitting in a cross-origin iframe where it can only do damage to itself.

Anthropic Model Names and Deprecations: Build a Changelog Habit

Ganesh Joshi — Sun, 11 Oct 2026 15:18:59 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Every model provider retires models. The identifier you pass in the model field is a version string with a lifecycle, and unlike your npm dependencies nothing in your toolchain tells you when it is about to end.

The failure is undramatic and annoying. A string that has worked for a year starts returning errors, and the person on call has to find where it is configured, which turns out to be five places, three of them not in the application repository.

Find every place the string lives

Before anything else, find out how many there are. In most codebases the answer is more than expected:

grep -rn "claude-" --include="*.ts" --include="*.py" --include="*.env*" \
  --include="*.yml" --include="*.tf" . | grep -v node_modules

The ones that hurt are outside the application code: a Terraform variable, a CI secret, a dashboard config, a seed script, a colleague's local .env. Each is a separate thing to update under time pressure, and the ones you forget fail later than the ones you find.

One module owns the mapping

Collapse them into a single place that maps a role to an identifier, and have the application refer to roles:

// models.ts is the only file that names a model.
export const MODELS = {
  chat: process.env.MODEL_CHAT ?? 'claude-sonnet-4-5',
  summarize: process.env.MODEL_SUMMARIZE ?? 'claude-haiku-4-5',
} as const;

// Everywhere else:
await client.messages.create({ model: MODELS.chat, ... });

The environment variable allows an override without a deploy, which is what you want during an incident. The default in code means a missing variable does not produce an empty model field and a confusing error.

Naming by role rather than by model is the part that pays off. MODELS.summarize stays meaningful across three model generations; CLAUDE_HAIKU_MODEL becomes a lie the first time you point it at something else.

Version the choice deliberately

Providers usually offer both a dated identifier and a moving alias. They fail in opposite directions.

Form	Behaviour	Risk
Dated, e.g. `claude-haiku-4-5-20251001`	Frozen	Sunsets on a schedule
Alias, e.g. a latest-style pointer	Moves	Behaviour changes without a deploy

For production, the dated form is usually right, for the same reason you commit a lockfile: you want the thing you tested to be the thing that runs. The cost is that you own the upgrade, which is the point.

Aliases are fine in development and evaluation environments, where discovering a change early is useful rather than alarming.

Subscribe, then check on a schedule

Providers publish deprecation notices in documentation and changelogs, and send console or email notices to account owners. Two habits close the gap.

Route provider notification emails to a shared inbox rather than an individual. Deprecation notices have a way of arriving while the person who set up the account is on holiday, or after they have left.

Then check the deprecations page as a recurring task, roughly monthly. That sounds primitive next to automation, and it is more reliable than most automation, because a page layout change silently breaks a scraper while a calendar reminder does not.

Make the upgrade routine boring

When a new identifier is available, the path should already exist:

Point staging at the new model via the environment variable.
Run your evaluation set against it and compare outputs to the current model.
Check cost and latency, since both frequently change.
Promote by changing the production variable.
Update the default in code so the variable is no longer load-bearing.

Step two is the one that requires prior investment. If you do not have a stored set of representative inputs with known-good outputs, every model change is a leap, and the only feedback is user complaints a week later. A few dozen cases is enough to catch a regression in format, tone, or refusal behaviour.

Cost and latency deserve their own check because they move independently of quality. A newer model that is better and three times the price is a product decision, not an automatic upgrade.

Fail loudly on an unknown model

Add a startup assertion that the configured identifier is one you recognise:

const KNOWN = new Set(Object.values(MODELS));
if (!KNOWN.has(configured)) {
  throw new Error(`Unknown model: ${configured}`);
}

A typo in an environment variable otherwise surfaces as a runtime API error on the first user request, in whichever code path happens to run first. Failing at boot puts the error in the deploy log, where someone is already watching.

None of this is sophisticated. It is the same discipline you already apply to dependency versions, extended to a string that behaves exactly like one but arrived through a different door.

Turborepo for AI Product Monorepos and Shared Pipelines

Ganesh Joshi — Sun, 04 Oct 2026 14:35:58 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

AI products fragment across runtimes quickly. There is a web app, one or more background workers doing embedding or evaluation, sometimes an edge function, and underneath them shared packages holding prompts, model adapters, and schema definitions. Every one of those consumers needs the shared code, and every change to it should rebuild exactly the things affected and nothing else.

That is what Turborepo is for. Most of the value comes from getting two things right: the task graph and the cache inputs.

Declare the graph, not the order

The ^ prefix means "this task depends on the same task in my dependencies", which is what makes a package build before the app importing it:

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**", "dist/**"]
    },
    "test": { "dependsOn": ["^build"] },
    "lint": { "dependsOn": [] },
    "dev": { "cache": false, "persistent": true }
  }
}

Two details are easy to get wrong. lint genuinely has no dependencies, so declaring one serialises work that could run in parallel across every package. And dev must be marked persistent and uncached, otherwise Turborepo waits for a long-running process to exit before starting anything downstream.

The outputs list is what gets restored on a cache hit. Omit a directory and a "cached" build leaves you without files you needed. Excluding .next/cache is deliberate: it is large, it is a cache of a cache, and storing it makes every hit slower to download than the build it replaced.

Environment variables are cache inputs

This is the mistake specific to AI projects, and it produces genuinely confusing failures.

Turborepo hashes inputs to decide whether a task can be restored from cache. Environment variables are not included unless you declare them. So if a build embeds a model name or an API base URL, and you change that variable, Turborepo sees identical inputs and hands back the old artifact.

{
  "tasks": {
    "build": {
      "env": ["MODEL_NAME", "EMBEDDING_MODEL", "NEXT_PUBLIC_*"],
      "dependsOn": ["^build"]
    }
  }
}

The symptom is a deploy that changes nothing. You switch the model, the build succeeds, and production keeps using the old one because the artifact was restored rather than rebuilt.

The reverse mistake matters too. Declaring a variable that changes on every run, such as a build timestamp or a CI job id, means the hash never matches and you never get a cache hit at all. If your hit rate is zero, this is almost always why.

Secrets should not be build inputs in the first place. An API key belongs in the runtime environment, not baked into an artifact, and adding it to env implies it can change the build output, which is a design you do not want.

Remote caching is the point in CI

Local caching helps one developer. Remote caching means a build produced on someone's laptop is reused by CI, and a build from CI is reused by everyone else.

For an AI monorepo where the web app and three workers all depend on the same prompt package, this is the difference between rebuilding four times and once.

Treat the cache token as a credential with write access to your build outputs. A leaked token that can write to the cache lets an attacker poison an artifact that your deploy then trusts. Give CI a token scoped to what it needs, and prefer read-only tokens anywhere that does not need to publish.

Scope commands so you are not building everything

The filter flag is what keeps day-to-day work fast:

turbo build --filter=web                # just the web app and its deps
turbo build --filter=...[origin/main]   # only what changed since main
turbo test --filter=@repo/prompts...    # the package and everything depending on it

The last form is the one worth internalising. A trailing ... means "and everything downstream", so after changing a shared prompt package you can test exactly the consumers that could be affected. That is the correct blast radius for a change to shared AI logic, where a prompt tweak can alter behaviour in three services at once.

Keep model adapters in their own package

A structural recommendation that pays off repeatedly: put the code that talks to model providers in a single package with a stable interface, and let every app depend on that rather than calling providers directly.

It gives you one place to add a new provider, one place to change timeout handling, and one place that fails type-checking when a response shape changes. In a monorepo without this, provider details leak into four codebases and a provider migration becomes four migrations.

It also makes the cache work in your favour. Changing a worker does not invalidate the web app, and changing the adapter invalidates exactly the things that use it.

Check the summary when something feels wrong

When a build is slower than expected or a change did not take effect, ask Turborepo what it decided:

turbo build --summarize

That writes a file listing every task, whether it hit the cache, and the hash inputs used. Comparing two summaries shows precisely which input changed, which is far faster than guessing at why a task rebuilt or, more often, why it did not.

Feature Flags for A/B Testing AI Models and Prompts

Ganesh Joshi — Sun, 27 Sep 2026 14:32:13 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Changing the model behind a feature is a deploy-sized decision dressed up as a config change. The output shape shifts, the latency profile shifts, the cost per request shifts, and none of it shows up in your test suite because the test suite does not call the model.

Feature flags are the right tool, but AI rollouts stress them in ways ordinary flags do not. The main differences are that the thing you are testing is non-deterministic, the quality signal is delayed, and a bad variant can be expensive rather than just broken.

Evaluate on the server, without exception

Model selection must never be decided by client code. A flag evaluated in the browser can be read and changed by anyone, which means the caller chooses which model you pay for.

// app/api/chat/route.ts
export async function POST(req: Request) {
  const session = await getSession(req);
  const variant = await flags.evaluate('chat-model', {
    userId: session.userId,
    plan: session.plan,
  });

  const model = MODELS[variant] ?? MODELS.control;   // fall back on unknown
  // ...
}

The fallback on an unknown variant matters. Flag services fail, configs get edited, and a variant name can disappear while sessions still reference it. Defaulting to the control means the worst case is no experiment, rather than an exception in your main request path.

Keep experiments and entitlements apart

These get conflated because both are "flags", and the consequences differ enormously.

An experiment decides which of two equivalent implementations a user gets. It can be reassigned, ramped, and rolled back freely. An entitlement decides what someone has paid for. It is authorisation, and it belongs with your billing logic, checked server-side on every request.

The failure is putting a paid capability behind an experiment flag. Ramp percentages then control who gets a feature they bought, and a rollback removes it from paying customers. Different systems, or at minimum different code paths with different review requirements.

Assign stably, or the data is noise

A user reassigned between variants mid-session gets a conversation where the model changes underneath them. That produces incoherent behaviour and contaminates your results.

Hash a stable identifier so assignment is deterministic:

function variantFor(userId: string, salt: string, split: number) {
  const h = createHash('sha256').update(`${salt}:${userId}`).digest();
  return (h.readUInt32BE(0) % 100) < split ? 'treatment' : 'control';
}

Include the experiment name in the salt. Without it, the same users land in the treatment group of every experiment you run, and effects compound invisibly.

For conversational products, consider pinning to the conversation rather than the user, so a single thread always uses one model even if the user's assignment later changes.

Decide what "better" means before you start

This is where AI experiments differ most from ordinary ones. There is no click-through rate for "gave a good answer", and the honest signals are indirect.

Signal	Reads as	Caveat
Explicit thumbs up or down	Quality	Very low response rate, skewed to extremes
Regeneration rate	Dissatisfaction	Also rises when responses are slow
Conversation length	Engagement or struggle	Ambiguous on its own
Task completion	Real success	Only measurable if the task has an endpoint
Cost and latency per request	Operational fit	Unambiguous, measure always

Pick the primary metric before launching. Choosing afterwards from whatever moved is how a worse model gets promoted on the strength of a metric that happened to rise.

Cost and latency are worth tracking on every variant regardless, because they are the two that are never ambiguous and they frequently decide the question on their own.

Log the assignment with the output

Every request should record which variant served it, alongside the tokens used, the latency, and any feedback that arrives later.

Without that join, you cannot attribute anything. A week into the experiment someone asks whether the treatment group's costs went up, and if the variant is not on the usage record, the answer is unavailable and the experiment was wasted.

Treat prompt text in these logs carefully. It is user content, and an experiment log is an easy place for it to end up with looser retention than the rest of your data.

Build the kill switch first

Ramp deliberately: internal users, then a small percentage, then wider. But the ramp matters less than the ability to stop.

A kill switch has to be a config change that takes effect immediately, with no deploy and no cache to wait out. Test that it works before you need it, and make sure whoever is on call can operate it without a code review.

The scenarios it exists for are specific and worth naming: a variant is producing unsafe output, a provider incident makes one path unusable, or the cost per request turns out to be several times the control. All three are discovered in production, and in all three the time between noticing and stopping is the entire cost of the mistake.

What to Check in an AI Coding Tool's Privacy Policy

Ganesh Joshi — Sun, 20 Sep 2026 13:25:47 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

"Does this tool upload my code?" is the wrong question, because the answer for every cloud-backed assistant is yes, at least sometimes. Completions require context, and context is your code.

The useful questions are narrower: which code, how long is it kept, who else sees it, is it used for training, and which of those answers change depending on a setting somebody can toggle.

This applies to any assistant. Vendor policies change, so what follows is a checklist to run against the current documentation rather than a summary of any particular product's terms.

What actually leaves the machine

Start here, because it is usually broader than developers assume. Beyond the file you are editing, an assistant may send surrounding files, imports it resolved, repository structure, and in agent modes the output of commands it ran.

That last category is the one that catches people. If the tool can run tests or a build, it can capture whatever those commands print, and build output routinely contains environment variables, connection strings, and internal hostnames.

Also worth establishing: does an indexing feature upload the whole repository, or only embeddings of it? Those are meaningfully different exposures, and both are usually described somewhere in the documentation.

The five things to find in the policy

Question	Why it matters
Is my code used to train models?	Usually configurable, and frequently defaults differently on personal and business plans
How long is it retained?	"Not trained on" and "not stored" are different claims
Which subprocessors receive it?	Your code reaches the model provider too, under their terms
Where is it processed?	Determines which jurisdiction's law applies
What is logged for abuse monitoring?	Often a separate retention path with a longer window

The subprocessor list is the one most often skipped and it is where the real answer lives. A tool that does not train on your code may still route it to a model provider that has its own retention policy. Read that provider's terms too, since it is the party actually holding the data.

Abuse-monitoring retention deserves specific attention. Providers commonly keep request data for some period for safety review even when the product tier promises no training and short retention. That is a defensible practice and it is a different number from the one in the marketing table.

Check the defaults, then check them again after an update

Almost every tool has a privacy mode that reduces or eliminates retention. Three things are worth verifying rather than assuming.

Whether it is on by default, and specifically whether that differs between free, pro, and enterprise tiers. Whether it applies to every feature, since a tool can honour it for completions and not for a newer agent mode. And whether it survives updates, because settings do occasionally reset or a new feature ships with its own separate toggle.

The practical version of this: after any major version update, re-open the privacy settings and look. It takes a minute and it catches the case where a new capability arrived with a permissive default.

For team and enterprise use

If the tool is being approved for a team rather than an individual, a few additional items belong on the list.

Whether an administrator can enforce the privacy setting centrally, rather than trusting each developer to configure it. Whether the vendor offers a data processing agreement, which you will need if any regulated data can appear in your codebase. Whether attestations such as SOC 2 are available on request, if your own contracts require them. And what the deletion path is, both for an individual leaving and for terminating the contract.

Ask specifically whether deletion covers backups and logs, and on what timeline. "Deleted from our systems" and "deleted from our backups within 90 days" are both reasonable answers, and only one of them is what most people assume they are getting.

Keep a dated record

When tooling is approved, save a dated copy of the policy as it stood, not just a link. Policies are updated without notice, and if a question arises later about what was agreed, a live URL cannot tell you what it said at the time.

A PDF or an archive link with the date is enough. This is unglamorous and it is exactly what an auditor or a customer security questionnaire will ask for.

The rule underneath all of it

Do not infer policy from forum posts, changelogs, or someone's confident summary, including this one. Read the vendor's current pages, note the date you read them, and re-check when the tool updates significantly.

The tools are genuinely useful and this is not an argument against using them. It is an argument for knowing what you agreed to, which takes half an hour once and is difficult to reconstruct later.

Redis Rate Limits for LLM API Keys and Tenant Quotas

Ganesh Joshi — Sun, 13 Sep 2026 13:37:35 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Rate limiting a normal API protects your servers. Rate limiting an LLM API protects your bank account. The difference matters, because it changes what you are counting and where the limit has to live.

A conventional web endpoint costs you CPU time measured in milliseconds. A single model call can cost real money, and an agent loop can issue hundreds of them without a human ever clicking anything. One customer leaving a misconfigured retry loop running overnight is a bill, not a blip.

Count tokens, not just requests

The instinct is to limit requests per minute. That is necessary but not sufficient, because requests vary in cost by three orders of magnitude. A one-line prompt and a 200-page document summarisation are both "one request".

Track both, and enforce whichever binds first:

// Two windows, different units, same tenant.
await Promise.all([
  consume(`rl:${tenantId}:req`, 1, 60),        // 60 requests / minute
  consume(`rl:${tenantId}:tok`, tokens, 3600), // 200k tokens / hour
]);

The request limit stops runaway loops quickly. The token limit is what actually caps spend. You need the second one before you need the first.

Key design is the whole security model

Every limit key must contain the tenant identifier, and that identifier must come from your authenticated session, never from the request body.

// Correct: identity comes from the verified session.
const key = `rl:${session.tenantId}:${operation}`;

// Wrong: caller controls their own bucket, so they control their own limit.
const key = `rl:${req.body.tenantId}:${operation}`;

That second version is not a rate limit. Anyone who reads their own network traffic can send a different tenant id and get a fresh quota, or send someone else's and exhaust theirs.

Include the operation in the key too. Embedding calls and chat completions have wildly different cost profiles, and a shared bucket means a bulk embedding job starves interactive users of the quota they are paying for.

A sliding window that does not drift

Fixed windows have a well-known flaw: a caller can send a full quota at 11:59:59 and another full quota at 12:00:00, which is double the intended rate across a two-second span.

A sorted set gives you a true sliding window. Each request is a member scored by timestamp; expired entries are trimmed on read.

-- KEYS[1] window key, ARGV: now_ms, window_ms, limit, member
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, ARGV[1] - ARGV[2])
local used = redis.call('ZCARD', KEYS[1])
if used >= tonumber(ARGV[3]) then
  return {0, used}
end
redis.call('ZADD', KEYS[1], ARGV[1], ARGV[4])
redis.call('PEXPIRE', KEYS[1], ARGV[2])
return {1, used + 1}

Running this as a Lua script matters. The trim, the count, and the insert have to be one atomic unit, otherwise two concurrent requests can both read used = limit - 1 and both proceed. Redis executes a script without interleaving other commands, which closes that race without a distributed lock.

The PEXPIRE on every call is deliberate. It means idle tenants expire out of memory on their own, so your key count tracks active tenants rather than every tenant you have ever had.

Reserve before the call, reconcile after

Token counts create an ordering problem: you cannot know the true cost until the response comes back, but you have to decide before sending it.

Reserve an estimate up front, then correct it:

const estimate = countPromptTokens(prompt) + maxOutputTokens;
const ok = await consume(`rl:${tenantId}:tok`, estimate, 3600);
if (!ok) throw new QuotaExceeded();

const res = await model.complete(prompt);

// Give back what was reserved but not used.
const actual = res.usage.inputTokens + res.usage.outputTokens;
await refund(`rl:${tenantId}:tok`, estimate - actual);

Reserving maxOutputTokens is pessimistic on purpose. Most responses come in well under the ceiling, and the refund returns the difference. The alternative, charging only actual usage after the fact, lets a tenant exceed their quota by the size of whatever is in flight when they hit the limit.

Fail closed on spend, open on latency

When Redis is unreachable you have to choose, and the right answer differs by limit type.

Limit	Redis down	Why
Requests per minute	Allow	Protects servers, and your servers are fine
Token or spend quota	Deny	Protects money, and money does not recover

An abuse-prevention limit failing open for thirty seconds is an acceptable risk. A spend cap failing open for thirty seconds during an agent loop is a genuinely expensive outage. Encode the difference rather than applying one blanket policy.

Watch the limiter's own latency

Every model call now waits on a Redis round trip first. That is cheap, but it is not free, and it sits directly in your user-facing path.

Two things keep it cheap. Put Redis in the same region as the service calling it, because a cross-region check can cost more than the limit saves. And pipeline the request and token checks into a single round trip rather than issuing them serially, as in the Promise.all above.

Measure the p99 of the check itself, separately from the model call. If it drifts upward, the usual cause is a sorted set that has grown large because the window is long and the traffic is heavy. A one-hour window on a busy tenant holds every request in memory for the full hour.

What to build first

Start with a per-tenant token quota on an hourly window, failing closed. That single control stops the failure mode that actually hurts, which is unbounded spend from one customer. Add per-operation buckets when a bulk job first starves your interactive traffic, and add request-per-minute limits when you see abuse rather than before.

Everything here depends on the key containing an identity the caller cannot choose. Get that right and the rest is tuning.

Where to Read Real AI Lab News: Anthropic, OpenAI, Google DeepMind

Ganesh Joshi — Sun, 06 Sep 2026 12:34:59 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

The gap between what a lab announced and what circulates about it is usually not misinformation. It is compression. A blog post says a capability is rolling out to a subset of users in some regions during a preview, and by the third repost it is "now available".

That distinction rarely matters when you are reading casually. It matters a great deal when you are deciding what to build, because you can spend a sprint on something your users cannot access yet.

The two source types that answer different questions

Announcements tell you what a lab wants to communicate. Changelogs tell you what actually changed in the API you are calling. Both are official, and they answer questions you should not confuse.

You want to know	Read
Is there a new capability, and what is it for	The announcement or research post
Did the endpoint I depend on change	The API changelog
What are the documented limits and failure modes	The model card or system card
Is a model I use going away	The deprecations page

For day-to-day engineering, the changelog and the deprecations page are worth more than the announcement. They are also the two nobody subscribes to.

A model card is the most underused document in the category. It typically states the evaluation setup, known weaknesses, and intended use, and it is written by the same people making the claim. Reading it takes ten minutes and answers most of the questions a launch post leaves open.

Three questions that resolve most of the confusion

When a capability is announced, the practical details are almost always in the post and almost always omitted from summaries:

Who can use it now? General availability, limited preview, waitlist, or a specific usage tier. This single distinction accounts for most of the disappointment when a team tries to use something they read about.

Where does it work? Region availability differs by product and by model, and an enterprise agreement can restrict it further.

What is the actual price? Announcements frequently quote a headline rate that applies to one model in one configuration. The pricing page is the source, and cached or batch rates often differ substantially from the number in the post.

If a summary does not answer all three, it has not told you enough to act on.

Aggregators are for discovery, not for detail

Social feeds and newsletters are good at telling you something happened. They are unreliable for the specifics, not because people are careless but because a headline cannot carry a limitations section.

The habit worth building is a hard split: use feeds to find out that something exists, then follow the link before forming a view. If there is no link to a primary source, treat the claim as unconfirmed. That single rule filters a surprising amount.

Benchmark numbers deserve particular suspicion when they arrive without context. A score is meaningless without the evaluation setup, and the difference between a model tested with tool access and without, or with several attempts and one, can be larger than the difference between models.

Make it a routine, not a feed

The version of this that survives contact with a busy week is small:

Subscribe the team inbox to the API changelogs of every provider you depend on. Not an individual's inbox.
Check deprecations monthly. Put it in the calendar.
When something looks relevant, read the model card before the announcement.
Write a two-line note in a shared doc: what changed, and whether it affects anything you run.

That fourth step is what turns reading into knowledge the team keeps. It also creates a record you can search when someone asks in six months why a particular decision was made.

Rotating who does it weekly spreads both the work and the context, and stops the whole team depending on one person's algorithmic feed.

Independent evaluation is worth waiting for

For anything genuinely surprising, the useful signal often arrives a few weeks later, when other groups have tried to reproduce it. Replication attempts and critical write-ups are less visible than the original announcement and considerably more informative about whether a result holds up outside the conditions it was measured in.

There is rarely a cost to waiting. The capability will still be there in three weeks, and by then you will know whether it does what the headline said.

The engineering version of this discipline is simple: cite what you actually read, and be able to point at where a claim came from. It costs a few minutes per decision and it is the difference between a team that knows what it is building on and one repeating a summary of a summary.

Vetted Access Programs: Frontier AI Security

Ganesh Joshi — Sun, 16 Aug 2026 09:23:41 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Unrestricted models like Mythos 5 are not gone. They are just locked behind vetting walls. If you want to use them for research, you must pass a compliance audit. We looked into the requirements.

To qualify for vetted access, your team must undergo a background check. You must document your security practices. You must prove you can store API keys in hardware security modules.

The process is slow. It takes weeks of paperwork and meetings. You need to prove your organization has a clean compliance history.

Submit organization registration and tax status documents.
Complete a cybersecurity compliance questionnaire.
Sign an agreement with strict export-control clauses.
Establish secure VPN tunnels to the provider's dedicated endpoints.

This vetting is the future of frontier AI development. We must adapt to these hurdles. Start hardening your API security practices today if you expect to use advanced models in the future.

DEV Community: Ganesh Joshi

Core Web Vitals When Your Hero Section Is an AI Chat

The chat should not be your LCP element

Reserve the space before the tokens arrive

INP belongs to the input box, not the model

Watch TTFB if the route is server-rendered

Measure in the field, not on your laptop

The short version

React error #418: five hydration bugs I shipped

1. Randomness or time in a useState initializer

2. Formatting with the machine's locale

3. Browser-only APIs while rendering

4. usePathname() in a prerendered component

5. A script that edits <body> before React gets there

How to find yours

Node Streams for Large RAG Uploads and Embedding Pipelines

Where the memory actually goes

Streams turn peak memory into steady memory

Backpressure is the part that matters

Batch the embedding calls

Make it resumable, because it will fail

Verify with the number that matters

“Mindblowing” AI Results? Read the Paper or Model Card First

Read it out of order

The questions that change what a number means

Model cards deserve more attention than papers

Wait for someone else to try it

What this looks like in practice

CSP and Third-Party AI Widgets: Copilot, Chat, and Scripts

The install instructions are the problem

Nonces instead of unsafe-inline

Know which directive each behaviour needs

Roll it out in report-only first

A widget you cannot trust belongs in an iframe

Test it on the built site, not in development

The shape of a good outcome

Anthropic Model Names and Deprecations: Build a Changelog Habit

Find every place the string lives

One module owns the mapping

Version the choice deliberately

Subscribe, then check on a schedule

Make the upgrade routine boring

Fail loudly on an unknown model

Turborepo for AI Product Monorepos and Shared Pipelines

Declare the graph, not the order

Environment variables are cache inputs

Remote caching is the point in CI

Scope commands so you are not building everything

Keep model adapters in their own package

Check the summary when something feels wrong

Feature Flags for A/B Testing AI Models and Prompts

Evaluate on the server, without exception

Keep experiments and entitlements apart

Assign stably, or the data is noise

Decide what "better" means before you start

Log the assignment with the output

Build the kill switch first

What to Check in an AI Coding Tool's Privacy Policy

What actually leaves the machine

The five things to find in the policy

Check the defaults, then check them again after an update

For team and enterprise use

Keep a dated record

The rule underneath all of it

Redis Rate Limits for LLM API Keys and Tenant Quotas

Count tokens, not just requests

Key design is the whole security model

A sliding window that does not drift

Reserve before the call, reconcile after

Fail closed on spend, open on latency

Watch the limiter's own latency

What to build first

Where to Read Real AI Lab News: Anthropic, OpenAI, Google DeepMind

The two source types that answer different questions

Three questions that resolve most of the confusion

Aggregators are for discovery, not for detail

Make it a routine, not a feed

Independent evaluation is worth waiting for

Vetted Access Programs: Frontier AI Security

1. Randomness or time in a `useState` initializer

4. `usePathname()` in a prerendered component

5. A script that edits `<body>` before React gets there