Meet the expert: Doug Bierer

Doug has been involved in the computer industry since the advent of microcomputers. His first program was written on a PDP-8 with a whopping 4K of RAM. Since that time, Doug has written applications for customers on four different continents, in over a dozen languages, including Assembler, FORTH, C, C++, Prolog, and Perl, as well as Java, Python, and PHP. He also has extensive experience in systems administration, networking, and database administration, including MySQL, Oracle, PostgreSQL, and MongoDB.

It’s absurdly easy to turn your PHP website into an AI-assisted powerhouse. No new dependencies, no extra service to stand up, just the PHP you already have installed. In this brief article, we’ll show you two ways to make a call to a GenAI platform.

What is a REST request?

A REST request uses standard HTTP methods (GET, POST, PUT, PATCH, and DELETE) to perform operations on resources identified by URLs. It is stateless, meaning each request contains all necessary information, and typically exchanges data in JSON or XML format. Both Streams (the standard PHP I/O functions) and the cURL extension can be used to make REST requests to external web services. In this recipe, we show you how to make requests to a remote GenAI REST service using both techniques.

Without further ado, let’s get right to it!

Identifying the goal

Before going any further, it’s important to identify our goal. For the purposes of this article, we’re going to make a REST API call to the openrouter.ai platform. The reason this platform is a great choice is because its single API can be used against any of the ever-changing sea of GenAI models available at any given moment.

Our ultimate goal is to emulate the following command line request:

curl https://openrouter.ai/api/v1/chat/completions 
-H “Content-Type: application/json” 
-H “Authorization: Bearer $OPENROUTER_API_KEY” 
-d ‘{ “model”: “mistralai/mistral-nemo”, “messages”: [ { “role”: “system”, “content”: “Just give me the name of the capital without any additional explanation.”}, { “role”: “user”, “content”: “What is the capital of France?” } ] }’

Making a REST request using PHP Streams

PHP Streams is a unified abstraction layer that lets you work with files, network connections, and data using the standard I/O functions (e.g., fopen, fread, fwrite). It handles protocols like HTTP, FTP, and data compression, operating on top of what the PHP documentation refers to as “wrappers“.

In this simple example, we’ll create a class SimpleAPICall that contains two methods that both connect to a GenAI API endpoint. The first method, streamsConnect(), uses PHP Streams to make the call. The other method, curlConnect(), described in the next section, uses the PHP cURL extension to make the call.

We start with a class opener that defines a couple of constants along with a method that returns the appropriate headers. You’ll note that our GenAI API key is stored in an environment variable OPENROUTER_API_KEY:

<?php 
class SimpleAPICall { 
 const API_GET_URL = ‘https://openrouter.ai/api/v1/chat/completions’; 
 const API_ERROR = ‘ERROR: api transmission error’; 
 public static function getHeaders() { 
 return [ ‘Content-Type: application/json’, 
 ‘Authorization: Bearer ‘ . getenv(’OPENROUTER_API_KEY’), ]; 
 }

Next, we define the method to connect using Streams. The most important aspect of this code is setting the context. This instructs file_get_contents() to send out the metadata defined in the context when making the API call.

public static function streamsConnect(array $data) : array
{
 try {
 $headers = self::getHeaders();
 $options = [
 ‘http’ => [
 ‘method’ => ‘POST’,
 ‘header’=> implode(”\r\n”, $headers),
 ‘content’ => json_encode($data, JSON_THROW_ON_ERROR),
 ]
 ];
 $context = stream_context_create($options);
 $text = file_get_contents(static::API_GET_URL, context: $context);
 $data = json_decode($text, TRUE, JSON_THROW_ON_ERROR);
 if (!empty($data[’error’])) {
 $response = [’success’ => false, 
 ‘data’ => ($data[’error’][’message’] ?? self::API_ERROR) 
 . ‘ [’ . ($data[’error’][’code’] ?? 400) . ‘]’];
 } else {
 $response = [’success’ => true, ‘data’ => $data];
 }
 } catch (Throwable $t) {
 error_log(__METHOD__ . ‘:’ . $t->getMessage());
 $response = [’success’ => false, ‘data’ => static::API_ERROR];
 }
 return $response;
}

Worth pausing on that context array for a second: everything you’d normally hand to curl on the command line (the method, the headers, the body) gets folded into one nested array and handed to stream_context_create(). file_get_contents() then treats the API endpoint exactly like any other URL, which is the whole point of Streams: HTTP is just another wrapper, not a special case.

Normally we’d return a JSON response, but in this case we’ll stick to an array response to keep things simple.

Making the call using the cURL extension

Next let’s have a look at making the request using cURL. To this end, we define a method curlConnect() as shown here:

public static function curlConnect(array $data) : array { 
 $send = json_encode($data, JSON_THROW_ON_ERROR); 
 $ch = curl_init(static::API_GET_URL); 
 curl_setopt_array($ch, [ 
 CURLOPT_HTTPHEADER => self::getHeaders(), 
 CURLOPT_CUSTOMREQUEST => ‘POST’, 
 CURLOPT_POSTFIELDS => $send, 
 CURLOPT_RETURNTRANSFER=> true, 
 CURLOPT_HEADER=> false, 
 CURLOPT_TIMEOUT=> 60, 
 // to make this work locally, set both CURLOPT_SSL* options to “false” 
 CURLOPT_SSL_VERIFYPEER => false, 
 CURLOPT_SSL_VERIFYHOST => false, ]); 
 try { 
 $text = curl_exec($ch); 
 $data = json_decode($text, TRUE, JSON_THROW_ON_ERROR); 
 if (!empty($data[’error’])) { 
 $response = [’success’ => false, 
 ‘data’ => ($data[’error’][’message’] ?? self::API_ERROR) 
 . ‘ [’ . ($data[’error’][’code’] ?? 400) . ‘]’]; 
 } else { 
 $response = [’success’ => true, ‘data’ => $data]; 
 } 
 } catch (Throwable $t) { 
 error_log(METHOD . ‘:’ . $t->getMessage()); 
 $response = [’success’ => false, ‘data’ => static::API_ERROR]; 
 } finally { 
 curl_close($ch); 
 } 
 return $response; 
}}

Notice how much of that is boilerplate you’ll reuse verbatim on every call: the headers, the POST method, the timeout. The only thing that changes between requests is $data, which is exactly why wrapping both approaches in a class like this pays off the moment you’re calling the API more than once.

And that ends the class.

Making the call

In order to make the call we set up a simple test program as shown here:

<?php
$data = [
‘model’=> ‘mistralai/mistral-nemo’,
‘messages’=> [
[
‘role’=> ‘system’,
‘content’=> ‘Only give me the name of the capital.’
],
[
‘role’=> ‘user’,
‘content’=> ‘What is the capital of France?’
]
]
];
$result = SimpleAPICall::streamsConnect($data);
print_r($result);
echo PHP_EOL;
$result = SimpleAPICall::curlConnect($data);
print_r($result);

We won’t show the output here to conserve space, but suffice it to say that the result is an array with values associated with this platform, including usage information (good to know if you’re concerned with cost control!), any error information, and, of course, the final answer: Paris. Have fun, and enjoy coding!

IMPORTANT: GenAI model selection is extremely important. Just the other day, I forgot to reset the default fallback. Later, to my regret, I was hit with a $43 bill after just one hour of use because the fallback was Claude Opus, one of the most expensive models!

This Week in the News

🎨 Linear's migration from styled-components to StyleX: After 1,000+ PRs, Linear ditched runtime CSS-in-JS for Meta's build-time compiled StyleX, betting that atomic, contract-enforced styles are safer for agents to touch than the old freeform cascade.

🦀 Bun ships 1.4, and it’s rewritten in Rust: Bun’s Zig-to-Rust rewrite finally landed, and it’s not just a fresh coat of paint. Idle CPU is down 5x, memory up to 35% lower, Linux startup 2x faster, plus new toys like Bun.Image, Bun.WebView (a headless browser with zero installs), and a built-in React Compiler. Ambitious doesn’t begin to cover it.

📝 How Cloudflare moved its own blog onto its new WordPress rival: Cloudflare just launched EmDash, a sandboxed-plugin CMS built on Astro, and promptly used it to migrate blog.cloudflare.com. Naturally, WordPress’s Matt Mullenweg wasn’t impressed, calling it a play to “sell more Cloudflare services.” Fair, but that’s kind of always the pitch with platform vendors.

💬 The Next.js team did a Reddit AMA, and it’s worth the scroll: No fluff here, just the team fielding real questions from the trenches. If you use Next.js and have opinions (you do), this thread is a rare unfiltered look at how the sausage gets made.

🦆 DuckDB’s creators are joining AWS: Werner Vogels hands the mic to Andy Warfield, who makes the case that single-machine hardware has quietly gotten so powerful that a huge chunk of “big data” work never needed a cluster in the first place. He also explains why DuckLabs is now joining AWS as a subsidiary while staying open source. A genuinely fun read on how the physics of computing keeps rewriting database design.

🖥️ OpenAI is quietly building a whole interface platform inside ChatGPT: Reverse-engineering of the Codex client turned up “GenUI,” a server-directed system that can keep updating parts of an answer after it’s been delivered, plus 467 versioned “Learning Block” modules covering everything from Bayes’ theorem to suturing technique. OpenAI hasn’t confirmed any of it, but the receipts (hashes, endpoints, and all) are pretty compelling.

Beyond the Headlines

🐛 How to report a bug so it actually gets fixed: A genuinely great walkthrough of turning a mystifying Netty ByteBuf leak into a Microsoft-shipped fix within weeks, not months. The trick is treating bug reports as a craft (bisect versions, shrink to a minimal repro, do the archaeology) rather than a complaint. Worth bookmarking for the next time something’s on fire.

⏱️ Notes on performance remediation strategies: Alex Russell’s latest on the never-ending fight against bloated, slow websites. Expect his usual mix of hard data and impatience with the industry’s excuses. Note: this one blocks bots, so go read it directly.

🈳 What language are agent skills actually written in?: A dig through 3.8 million SKILL.md files on GitHub finds 14.3% aren’t in English, and that share is climbing fast, led by Chinese and European-language skills. The twist: non-English skills get revised more but copied less, suggesting good work is getting made outside the Anglosphere and then just not found.

🎙️ Anders Hejlsberg on rewriting TypeScript for 10x speed: The creator of TypeScript and C# on why the compiler moved to Go, why JavaScript keeps winning, and his grounded take on AI's real impact on software engineering.

🔌 WebSockets vs. SSE should really be about ordering, not vibes: José Valim’s rebuttal to the “just use SSE, latency’s the same” HN take. The real issue is that splitting updates across two streams invites race conditions your UI won’t recover from without a refresh, and bidirectional WebSockets sidestep this by construction. A sharp, opinionated read for anyone architecting real-time UIs.

Tool of the Week

⌨️ TermDOM: build terminal apps with actual HTML, CSS, and the DOM: No proprietary Box/List/Screen widgets to learn. TermDOM implements a real, spec-compliant DOM and CSSOM and paints it to ANSI escape sequences, meaning flexbox, :focus styles, and even unmodified browser libraries (Prism.js syntax highlighting!) just work in your terminal. Delightfully weird and clearly well-built.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the expert: Jia Huang

Jia is an AI researcher at A*STAR, Singapore, and a technical author who writes about how AI agents are engineered.

He proposed the dual-axis framework for agent design patterns, which classifies patterns by cognitive function and execution topology, and the Pattern Selection Card, a practical method for choosing patterns under real cost and latency constraints. His work focuses on the engineering that surrounds the model rather than the model itself: context, tools, execution environments, and governance.

Imagine this. Two developers use the same coding assistant on the same Tuesday afternoon. One ships a clean refactor across a dozen files before lunch. The other spends three hours fighting a model that keeps rewriting code it was told to leave alone, reads the same file four times, and confidently edits a config file that doesn’t exist.

Same model. What changed was everything around it.

That gap is the most useful thing to notice as teams adopt AI-assisted development. The industry argues about models: which one reasons better, and whose benchmark score moved this month. For the day-to-day work of building software, the model stopped being the bottleneck a while ago. What decides whether an assistant saves your afternoon or eats it is the harness you build around it.

Before we get into it, here’s what the other half of this issue has in store for you:

• 🐙 GitHub’s postmortem reveals a platform straining under AI agents

• 🔮 Gary Marcus catches Sam Altman’s selective apology on AI timelines

• 🔦 A 2kb syntax highlighter with no DOM spans

• 🎬 TanStack Start’s take on React Server Components

• 🐛 Node 24.19 may be eating your memory

Where the harness actually does the work

A language model is stateless: it forgets everything between calls, has no standing knowledge of your repository, no memory of yesterday’s decision, and no way to run anything on its own. Left to itself, it’s a very good text predictor with amnesia.

Everything that makes it feel like a teammate lives in the layer around it: the context you feed in, the tools you let it call, the checks that run before its actions take effect. Borrowing a term from the agent world, call that layer the harness. The model reasons. The harness decides what reaches the model and what the model is allowed to do with the answer.

Web developers already build harnesses; they just don’t call them that: a CI pipeline is a harness around a compiler, a linter and pre-commit hook are one around a careless commit, and environment config and CORS rules are one around a browser. None of it makes the underlying thing smarter, just safer to rely on. The same move works on a language model, and most of the leverage in AI-assisted development sits there, not in the model version number.

Three lessons keep repeating.

Lesson 1: Treat context like a build artifact

The first instinct is to explain the project in the chat window, every time. It works for one task and evaporates on the next, because the model kept none of it.

The pattern that holds up is to treat the assistant’s standing context as something you build once and check into the repo, the way you’d write a README the tool actually reads. Claude Code calls this a CLAUDE.md file; other assistants have their own version. The format matters less than the discipline. Project conventions, the commands that build and test, the directories that are off-limits, the two or three decisions every newcomer gets wrong. Written down once, loaded on every task.

The surprising part is length. The temptation is to write everything down, on the theory that more context means fewer mistakes. Past a point it reverses: the one instruction that matters gets buried among fifty that don’t, and the model follows it less reliably, not more. The guidance that has held up in practice is to keep that standing file short, on the order of a couple hundred lines, and push everything else into files the assistant pulls in on demand. A short, dense context beats a long, complete one.

Lesson 2: What it can touch matters more than how smart it is

What actually determines safety isn’t how smart the assistant is, it’s what it can touch.

An assistant that can only read files and propose a diff cannot drop your database, no matter how badly it misreads a request. One with an open shell can. The boundary does more to define the agent than the prompt does. Web developers already know this shape: least privilege, scoped API keys, a service account that can read the one table it needs and nothing else.

A common failure runs the other way. A team wires up an assistant with broad command access, then tries to make it safe by asking nicely in the prompt: please don’t run destructive commands. The prompt is not an enforcement layer. The model will comply almost every time, and the almost is where the incident lives. Reliability came from narrowing what the tool could do, never from a more careful sentence.

In practice: start the assistant with the smallest set of capabilities that lets it do the task, and widen only when a real task demands it. What it knows is cheap to expand later. What it can do is where the risk sits, so that is the thing you gate.

Lesson 3: Make the important stuff deterministic

The parts of the harness that carry the most weight are the least glamorous. They are ordinary deterministic code that runs at fixed points, whatever the model decides.

There’s a check that blocks any edit touching a secrets file, a formatter that runs after every change so the model never gets to argue about style, and a rule that a test must pass before a change is allowed to land. None of it involves the model, but it all constrains it. Claude Code exposes these as hooks; the idea is far older than any agent framework, and web developers ship it every day as pre-commit hooks, CI gates, and middleware.

The first time a format-on-every-edit rule runs, it feels like overkill. The tenth time the model reindents a file its own way and the rule quietly normalizes it back, you stop noticing the disagreement at all. A whole category of friction got absorbed by three lines of deterministic code that never asked the model’s opinion.

The mental shift is to stop hoping the model behaves and start making the misbehavior impossible to commit. A probabilistic system will occasionally do the wrong thing; that is what probabilistic means. You don’t engineer that away by lowering the probability with a cleverer prompt. You put a deterministic gate on the actions that would actually hurt, so the occasional wrong decision has nowhere to land. This is process isolation and the fail-safe default, forty-year-old ideas, pointed at a new kind of unpredictable component.

A rough decision order

When an assistant misbehaves, reaching for a better prompt is usually the wrong first move. A more useful order:

• If the output is sloppy or wrong, fix the context first. The model is probably missing a convention nobody told it.

• Is the action dangerous or irreversible? That’s a tool-scope problem, not a wording one. Take the capability away.

• For anything that must never happen, build a deterministic guardrail instead of trusting the model’s judgment.

• Only once you’ve worked through all three should you bother rewording the prompt.

Prompts are the layer people adjust, since it’s the one visible in the chat box, and also the weakest lever you have. The harness is where the reliability comes from, and it’s mostly invisible until you go looking for it.

The math that changes the argument

There’s a cost argument that quietly settles most tooling debates, and it has nothing to do with token prices.

The reflex is to reach for the cheaper model to shrink the API bill. But the API bill is rarely the real cost. If a stronger model finishes a task in five minutes and a weaker one needs thirty minutes of a developer’s back-and-forth, the “expensive” model is the cheaper choice by a wide margin once you count the salary attached to those extra twenty-five minutes. Engineer-hours dwarf token spend. Put both on the same ledger and a surprising number of default choices flip.

The same accounting justifies the harness itself. A day spent writing the context file, scoping the tools, and wiring two guardrails feels like pure overhead. It pays for itself the first time it turns a wasted afternoon into a clean morning, and it keeps paying on every task after that.

The harness outlives the model

There’s a second reason to spend your effort here. Models turn over every few months; the harness mostly doesn’t. A context file, a scoped tool list, and a set of guardrails written for one assistant carry over almost unchanged when a stronger model ships, or when the team moves from one tool to another. The conventions your project needs, the actions that must never run, the tests that gate a merge: none of it depends on which model sits behind the chat box. Tune a clever prompt for this week’s model, and you’re renting; build the harness instead, and you own something that survives the next release, and the one after it.

Putting it together

The model version you’re on matters less than it feels like it does in the release-day threads. What compounds is the harness:

• Write the assistant’s standing context once and check it in. Keep it short enough that the important line isn’t buried.

• What the assistant can do matters more than what it knows, so scope that first.

• Rules that must not break belong in deterministic code, not a polite prompt.

• Cost the work in engineer-hours, not tokens.

None of this is new engineering. It’s the same discipline web developers already apply to compilers, browsers, and build pipelines, turned toward a component that happens to reason in English. Point it at a language model and it does the same job it always did: it takes a brilliant, forgetful, occasionally reckless part and makes it something you can build on.

The model gets the headlines, but the harness is what gets the work done.

By Jia Huang

This Week in the News

🐙 GitHub's postmortem reveals a platform straining under AI agents:
GitHub now handles roughly 2.9 billion commits and 130 million merged pull requests a month, and it's showing. The August 17 outage, its second that month, lasted nearly eight hours, and CTO Vlad Fedorov admitted the team needs to move faster. New git hosts are stepping into the gap: Origin from Cursor's team, Pierre with its API-first approach, and Cloudflare's Git-speaking storage layer are all vying to be your team's next home for code.

🔮 Gary Marcus catches Sam Altman’s selective apology on AI timelines:
Altman admitted he misjudged how fast businesses would adopt AI, but Marcus says he’s dodging the bigger miss: AGI. He digs up an Altman quote from January 2025 claiming confidence in “how to build AGI,” yet 19 months later even the best models still can’t be fully trusted. Marcus’s take: adoption jumps once AGI actually arrives, and that’s still years and several breakthroughs away.

🍁 Solid 2.0 lands, and Cursor jumps ship right on cue: Solid.js shipped its biggest rework yet with the Solid 2.0 RC. Almost in the same breath, Cursor engineer Lauren Tan confirmed Cursor has quietly migrated off Solid and onto React. Awkward timing aside, worth reading both the release notes and the thread.

🏗️ Lovable rebuilt its own site while nobody was looking: Lovable spent six months migrating its 42M visitor, 850K line website off Next.js onto their own TanStack Start stack, mostly by directing agents at individual components. An unrelated JSON change once pushed a worker over its memory limit and took part of the site down for 11 minutes. Honest, detailed writeup.

🐛 Node 24.19 may be eating your memory: Several teams are reporting out of memory crashes after upgrading from Node 24.18.1 to 24.19.0, and rolling back fixes it. Nothing confirmed yet, so add your data to the issue if you’re affected.

🏄 A browser built for agents, not humans: Kitesurf is a browser engine that runs on Cloudflare Workers with one isolate per page. Built for agents rather than people, it uses 3 to 7 times less CPU and memory than Chromium, at the cost of being slower. You can try the beta now, and it’ll be open sourced later.

Beyond the Headlines

⚙️ Cursor explains why hosting Git at scale is brutal: A long, sharp writeup on why Git hosting breaks down past a certain scale, and why GitHub’s Spokes system hits a wall with three phase commit past a few replicas. Cursor’s answer is Continuity, a write ahead log on S3 that treats every repo copy as disposable. Great systems reading either way.

✍️ A cleaner way to stroke text in CSS: A short, practical post on why -webkit-text-stroke has always looked slightly off, since it strokes over the fill instead of behind it. Covers a cleaner approach to outlined text without stacking shadows or reaching for SVG. Quick read, useful if you style headline text.

🎬 TanStack Start’s take on React Server Components: A TanStack Start talk arguing that RSC is a primitive, not an architecture. It walks through server functions that return RSC streams, caching them in the router or query cache, and composite components that let the client, not the server, decide what goes where. Solid mental model even if you don’t use TanStack.

🐢 Progressive enhancement belongs inside your JavaScript too: Remy Sharp rebuilds a small markdown tool so dropping a file before the parser has loaded doesn’t just navigate away to the raw file. The fix binds a lightweight listener first and queues the interaction until the heavy JS arrives. A good reminder that fast connections hide real UX bugs.

Developer Toolbox

🖥️ A Mac terminal that flags which agent needs you: Saggar tracks coding agent sessions across projects and surfaces which ones are waiting on you, which are still working, and which finished a while ago. There’s a phone companion for approving prompts remotely. Mac only, Apple silicon required, built for people running several agents at once.

🔦 A 2kb syntax highlighter with no DOM spans: Dave Rupert’s MicroLighter uses the CSS Custom Highlights API instead of wrapping tokens in spans, borrowing TextMate grammars so it can highlight almost any language on demand. No bold or italics yet, a real limit of the underlying API. Ships as ESM or an optional web component.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the expert: Chris Barin

Chris Barin, who penned the write-up below, is a professional web and app designer, an Adobe Certified Instructor, and a Certified Photoshop Expert with nearly 10 years of experience. Self-taught, he has earned the trust of over 300,000 students worldwide with a hands-on, no-nonsense approach focused on getting maximum results with minimal effort. He started out as a freelance web designer and today runs a 20-strong Android design studio whose apps have surpassed 100 million downloads.

I have been teaching design since 2013, with a focus on web and app design, and I have worked on both sides of the client relationship: as a freelance designer delivering the work and as an entrepreneur hiring people to deliver it. That perspective has made the current AI conversation feel strangely familiar.

Every day brings another announcement. A model can build a landing page, create a polished product image, generate a component, or connect to a design tool. The implied message is always the same: learn this now or fall behind.

That is a powerful way to create anxiety and sell more pricey design subscriptions from AI companies that are incredibly money-hungry.

The web professionals who thrive in the AI era will not be the ones who subscribe to every platform or memorize every feature. They will be the ones who move their attention up the stack: away from producing shiny stuff and more toward understanding the problem, directing the work, verifying the result, and improving the business outcome.

In short: help the company grow. Help the company achieve its goals. The company didn’t hire you to create a sleek product that’s going to look great in your portfolio. No, they hired you to increase their conversion rate, reduce churn, improve onboarding & retention, and other clear-cut objectives.

AI does not remove the need for developers. It changes where good developers create the most value.

Speaking of which, a few stories this week get at exactly that shift:

🔍 Anthropic Is Watermarking Claude's Text, Here's Where It Hides
⚡ MCP Just Went Stateless, and That Changes Everything
💻 Airtable Sold for $1.28B, Is No Code Already Dead?
🕵️ We Put GitHub Copilot Behind a Proxy, Here's What It's Really Sending
📦 Docker Sandboxes Make YOLO Mode Actually Safe for Coding Agents
📄 anydoc Converts Any Office File to Markdown, Right in Your Browser

Execution is becoming abundant

Consider a routine request: build a promotional landing page for a new product. A capable AI tool can one-shot it – meaning it can create something awesome based on one single prompt. It can scaffold the page, write responsive CSS, suggest copy, create image variations, and revise the result without becoming tired or defensive.

From a client’s perspective, that combination is difficult to ignore. The turnaround is fast, the initial quality is often acceptable, and requesting another version creates almost no social friction. The tool does not sigh when the client changes his mind 10 times and then comes back to the initial version.

This does not mean the entire web development profession has become a commodity. It means that parts of the job that were expensive because they consumed time are becoming cheaper. Boilerplate, first drafts, routine transformations, and basic variations are no longer where a developer can safely build a long-term advantage.

Think of AI as an electric screwdriver. It can help an experienced person assemble something much faster. It can also help an inexperienced person damage the material. The tool amplifies the judgment of the person holding it.

The important question is therefore not, “Can AI build this page?” It is, “Who can tell whether this is the right page, for the right audience, with the right trade-offs?”

Stop shipping features and start shaping outcomes

Suppose an online food brand asks for a new product page. A feature-focused team might discuss the framework, component library, image carousel, nutrition table, and checkout integration. Those choices matter, but they do not answer the customer’s real questions.

The customer is not buying 12 grams of fiber. That’s too zoomed in. The client is looking for a better breakfast, fewer digestive problems, or a way to eat well on a busy morning. The business does not merely need a nutrition component. It needs a page that connects the product to one of those motivations and then makes purchasing feel safe and easy.

This is where an intermediate developer can become far more valuable than someone who simply converts a ticket into code. Ask what behavior the feature is meant to change. Ask which audience matters most. Ask what evidence would show that the change worked.

More output should produce more learning

Before generative AI, a team might have had enough time and budget to explore two or three substantially different directions. Now it may be possible to produce ten. That sounds like a simple productivity win, but volume alone is not valuable. Ten untested variations are just a larger pile of opinions.

The real advantage is faster learning.

Instead of asking AI for ten cosmetic versions of the same hero section, create three distinct hypotheses. One page can emphasize convenience. Another can lead with the customer’s frustration. A third can focus on trust, proof, and product quality. Decide in advance which metric each direction is meant to influence, then instrument the experience and observe what happens.

This changes the developer’s role. You are not only implementing the selected design. You are helping the team create a system in which decisions can be tested. Feature flags, analytics events, performance budgets, accessible interaction states, and clean experiment boundaries become part of product thinking rather than chores added at the end.

There is an important limit here: more variants do not automatically create reliable evidence. A low-traffic product may not support a complex experiment, and small metric movements can be noise. The point is not to A/B test everything. The point is to replace taste and confidence with hard data.

Use AI to expand the option space, then use engineering discipline to reduce uncertainty.

Do not build your workflow around the model leaderboard

Tool comparison can become a full-time hobby. One developer says a platform is astonishing; another says it is unusable. Both are right. Results vary with the task, the context provided, the codebase, model updates, and the way a particular person works.

For most developers, the gap between learning a tool and constantly switching among several strong tools is more important than the gap between the tools themselves. Otherwise said – practice one kick ten thousand times, exactly like Bruce Lee famously said.

Choose a platform that fits your budget and environment. Give it real work for a few weeks. Learn where it tends to misunderstand your architecture, invent APIs, broaden scope, or produce code that looks finished before it is production-ready. Create a repeatable way to supply context and define what success means.

The most important skill is not knowing which AI platform tops the charts today. It is knowing how to frame your work, constrain it, and verify it when the tools change tomorrow.

Make the outcome clear

When output becomes cheap, verification becomes more important. “The page looks right” is not a sufficient completion signal for work that affects real users.

Before asking an AI to implement a meaningful change, write down five things:

• The user problem: What frustration or unmet need are we addressing?

• The intended change: What should the user be able or more likely to do?

• The constraints: What must remain stable, secure, accessible, and fast?

• The done signal: Which tests, checks, and acceptance criteria must pass?

• The learning signal: Which metric or qualitative evidence will we examine after release?

This short brief is useful even if you never show it to an AI. It forces the team to separate an implementation request from a product decision.

It also gives automated tools something concrete to work against. Type checks, tests, lint rules, accessibility checks, performance budgets, schemas, and observable acceptance criteria turn part of the team’s judgment into a repeatable gate. They do not eliminate human review, but they prevent reviewers from carrying every requirement in their heads.

The goal is not autonomous coding at any cost. The goal is delivery that you can count on.

Build a portfolio of results, not tools

A tool badge ages quickly. A case study built around an outcome does not.

If your portfolio says you used a particular framework or AI platform, it proves that you encountered the tool. If it explains how you reduced checkout friction, improved task completion, made a page measurably faster, increased qualified sign-ups, or reduced support requests, it shows that you understand why the work exists.

Getting that evidence requires curiosity after the pull request is merged. Ask for access to the relevant analytics. Talk to design, marketing, support, and operations. Watch how the feature behaves in production. Propose a small follow-up change that is inexpensive to test. Record what worked, what failed, and what you would do differently.

This is one reason proximity to the business matters. When developers only receive isolated tickets, they see requirements. When they talk to the people around the product, they see patterns: the repeated customer question, the manual workflow everyone accepts, the form users abandon, or the internal tool that costs hours every week.

Being an introvert is no longer an option. You have to talk to people and get their perspective. Clients have many choices when it comes down to skilled developers. Your moat now becomes how affable you are. How you make the client feel like. How you interact with his team. Soft skills are the biggest thing in an AI future.

A change for your next sprint

You do not need to reinvent your role or become a product manager. Start with one feature in your next sprint.

Before implementation, replace the ticket title with a one-sentence outcome. Identify one meaningful constraint and one signal you can observe after release. Ask AI to help explore genuinely different approaches, not merely different syntax. Choose an approach deliberately, implement it with mechanical checks, and return to the data after users encounter it.

Then write down the lesson.

You’re not replacing a landing page because it’s ugly. You’re doing it to improve certain KPI.

Repeat this and you will accumulate something more valuable than prompt tricks: a body of evidence about how product decisions, interface choices, technical constraints, and user behavior interact.

The tools will keep changing. Some tasks will become dramatically faster, and some skills that once looked central will become background knowledge. Prompt engineering is a great example – 12-18 months ago it was an essential skill, now it’s nearly irrelevant.

Businesses will still need people who can identify the destination, make trade-offs, recognize weak output, and connect software to a real result.

AI can do more of the driving. Your job is to choose where the product should go, keep it on the road, and know whether arriving there made anything better.

This Week in the News

🔍 Where an AI Watermark Can Hide in Plain Text: Anthropic quietly announced it’s watermarking Claude’s text output, but won’t say how. This piece makes a compelling case that the mark most likely lives in word-choice statistics, not hidden characters, which is exactly why copy-paste doesn’t kill it but a real paraphrase does. Worth reading if you’ve ever wondered whether “AI detection” is even the right question to ask.

🎨 State of CSS 2026: Nearly 5,000 developers weighed in, and Anchor Positioning is the runaway favorite feature, despite (or because of) still being a browser-support minefield. The more telling stat: CSS code is still 76% hand-written, making it one of the last corners of the frontend stack that AI hasn’t fully colonized. A fun state-of-the-union for anyone shipping styles in 2026.

⚡ The next generation of MCP: MCP just went stateless, and that’s a bigger deal than it sounds. It means agent servers can now run as plain Workers instead of babysitting sticky sessions and open streams. If you’ve ever cursed session management while building an MCP server, this is the fix you didn’t know you were waiting for.

🚂 Agents on Rails: The LLM Benchmark Project: The Rails Foundation commissioned Evil Martians to stop the vibes-based debate and actually benchmark which coding agents write good Rails code, at what cost, in how many tokens. Refreshing to see a language community demand receipts instead of just repeating “Rails and AI pair well” anecdotally.

Beyond the Headlines

💻 The End of No Code: Airtable just sold for $1.28B, and this piece argues that’s the No Code industry peaking, not thriving, because coding agents have made “just build it on Linux” cheaper than learning a proprietary platform’s quirks. A provocative, if self-interested (the author sells VMs), read on where internal tools are headed.

✍️ 5 CSS Properties You Should Know for Better Text Designs: A tidy grab-bag of underused CSS, like background-clip: text and box-decoration-mode, for anyone whose typography still looks like a Bootstrap default. Nothing revolutionary, but the letter-spacing reveal-animation trick alone is worth stealing.

🕵️ I Put GitHub Copilot Behind a MITM Proxy. Here’s What I Found.: This is the deep-dive every AI coding tool user should read: Copilot keeps a full local SQLite history of your prompts and responses in plain text, no redaction, and will happily send unrelated file content (including stray secrets) to the model as “recent edits” context. The real takeaway isn’t the leak, it’s that context, not the model, is quietly becoming the product.

🏗️ Angular Architecture Guide To Building Maintainable Applications at Scale: A solid, if Nx-flavored, refresher on ditching layered folders for domain-driven boundaries in Angular apps: feature, UI, and data-access libraries, with enforced dependency rules. Useful even if you never touch Nx, since the “thin app shell, fat domain libraries” mental model travels well.

😤 “Code was never the hard part” is an insult to all programmers: A sharp, funny rebuttal to the increasingly common AI-era take that coding was always the easy bit. The “if coding is easy, why isn’t everyone just building ten variations of a thing” line alone makes this worth the five minutes, a good gut-check before you nod along to that narrative again.

🦀 Understanding the Rust hype for the busy developer: A no-holy-war explainer aimed squarely at people who’ve heard “Rust is great” for years but never got a straight answer why. If you keep meaning to figure out what the fuss is about without committing a weekend to the Rust Book, this is the shortcut.

Developer Toolbox

📦 Docker Sandboxes: MicroVM-isolated, disposable sandboxes purpose-built for running Claude Code, Copilot CLI, Codex, and friends in full YOLO/--dangerously-skip-permissions mode without risking your actual machine. If you’ve been letting coding agents run wild locally out of laziness rather than confidence, this closes that gap cheaply.

📄 anydoc: A blazing-fast (sub-5ms median), pure-Rust converter that turns Word, PowerPoint, Excel, PDF, and more into clean Markdown, running entirely as WebAssembly in your browser so files never leave your machine. The most refreshing pitch here is the benchmark claim: only converter of seven tested that handled all fourteen formats.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the expert: Fabio Biondi

Fabio Biondi is a freelance developer and instructor who has dedicated his professional life to technical education, mentoring thousands of developers.

Recognized as a Google Developer Expert (GDE) in Angular since 2018, he has devoted himself to mastering frontend technologies before expanding his focus to generative AI.

Through his platform Learn by Do.ing, and presence on social media, Fabio regularly shares technical videos and insights. His mission continues to be empowering the dev community by evolving from core web technologies to the latest innovations in artificial intelligence.

If you’ve been telling yourself that “getting into AI” means wrestling with heavy toolchains, build steps, and a wall of configuration, here’s some good news: it has never been simpler to start. In fact, thanks to recent changes in Node.js, you can go from an empty folder to a working AI request in a few seconds.

For years, this is genuinely how it felt. You wanted to try a new model, and before you’d written a single line of actual logic, you were neck deep in a tsconfig.json, a webpack config, a babel setup, and three different flavors of module resolution. By the time everything compiled without errors, the excitement was gone. That friction wasn’t imagined. It was the real reason so many curious developers never got past “I should try this AI stuff sometime.”

What changed is not the AI itself, but the plumbing around it. Node.js closed the gap between “I have an idea” and “I have working code,” and that helped more than any single model release.

When the setup cost drops to zero, the only thing left standing between you and your first request is deciding to write it. And unlike a lot of shiny developer trends, this one costs nothing to try: no license, no signup wall beyond a free API key, no dependency tree to untangle before you even see output.

Node & TypeScript with zero config

Modern Node.js (v24+) can run TypeScript files natively. No tsc, no ts-node, no bundler. Node simply strips the types and runs the file. That means a “project” can be as small as a package.json with two lines that matter:

{

“type”: “module”,

“scripts”: { “start”: “node index.ts” }

}

”type”: “module” enables modern import/export syntax, and node index.ts runs your TypeScript directly. That’s the whole setup.

It’s worth pausing on what “strips the types” actually means, because it’s the whole trick. TypeScript was never a language the JavaScript engine understood on its own; it was always a superset that got compiled away before execution. Tools like tsc, ts-node, esbuild and Babel existed purely to do that translation, and each one came with its own configuration surface, its own quirks, and its own way of breaking on a Tuesday afternoon for no obvious reason.

Node’s native support skips that translation step entirely for straightforward TypeScript syntax. Type annotations are simply erased at parse time, the same way comments are ignored, and the underlying JavaScript runs untouched. There’s no source map to manage, no separate build artifact to keep in sync, no watcher process chewing through your CPU in the background. You edit the file, you run the file, and Node does the rest.

This matters more for a newsletter about AI than it might first appear. It means the code samples you see below, and the ones you’ll eventually write yourself, are not simplified for teaching purposes. They are the actual production shape code, with nothing hidden behind a build step you can’t see. What you read is what runs.

Now, add AI

This is the part people overestimate. Talking to a real Large Language Model is just a function call. You can pick any library or AI framework, install its package, and start experimenting in a handful of lines.

Strip away the marketing language around “AI integration” and what’s left is refreshingly mundane: you send some text to an endpoint, and the endpoint sends text back. That’s genuinely the whole mental model you need to hold onto. The model itself, whether it’s Gemini, Claude, GPT or anything else, is just a very sophisticated function sitting behind an HTTP request. You give it a prompt, it gives you a completion, and everything else you’ve heard about “agents,” “chains” or “pipelines” is scaffolding built on top of that one basic exchange.

Every provider wraps this exchange in an SDK so you don’t have to construct raw HTTP requests by hand, but the SDK is a convenience, not a requirement. Once you’ve made one of these calls successfully, you’ve effectively made all of them. The parameters change (which model, what temperature, whether you stream the reply token by token), but the shape of the call stays remarkably constant. That’s why the setup below only takes three steps.

For example, to get started with Gemini:

1. Install the package: npm install @google/genai:

2. Grab a free API key from Google AI Studio

3. Write your index.ts file:

import { GoogleGenAI } from “@google/genai”;

const ai = new GoogleGenAI({ apiKey: YOUR_GEMINI_KEY });

const res = await ai.models.generateContent({

model: “gemini-3.5-flash”,

contents: “Explain what an LLM is, in one sentence”,

});

console.log(res.text);

Now you can simply run the script in your terminal using npm start and wait for the result.

Let’s unpack that handful of lines, because each one is doing a specific, deliberate job. The apiKey you grab from Google AI Studio is what authenticates your request. It’s the equivalent of a password that tells Gemini’s servers “yes, this request is allowed to happen, and here’s who to bill for it.” Never commit that key to a public repository. For anything beyond a quick local experiment, pull it from an environment variable instead of pasting it directly into your source file.

The model field is where you choose which version of Gemini answers your prompt. Providers typically offer a range of models trading off speed, cost, and capability, and swapping between them is usually as simple as changing this one string; no other code needs to move.

The contents field is your prompt, the actual instruction or question you want answered. In this example it’s a single string, but the same field can just as easily hold a full back-and-forth conversation history, an image, or a mix of text and files, which is how multimodal requests work under the hood.

Finally, res.text is the model’s reply, already extracted and ready to use. Behind that convenient property sits a larger response object carrying metadata like token usage and finish reason, but for a first script, that one line is all you need to see something come alive on your screen.

That’s it. No build step, no framework, no boilerplate, just a few lines and your first AI-generated response prints to the terminal. From here, everything else (streaming, chats, images and videos generation, tool calling or MCP integration) is a variation on this same call.

Streaming, for instance, is the same generateContent call with a different method name, and instead of waiting for the full answer, you get the response piece by piece as the model generates it, which is what powers that familiar “typing” effect you see in chat interfaces. Multi-turn chats are just an array of previous messages passed back in with each new request, so the model has context on what was already said. Tool calling and MCP let the model request that your code run a function on its behalf, checking a database, calling an API, doing a calculation, and feeding the result back in before it finishes its answer. None of these are architecturally different from the nine lines you just ran. They’re the same idea, repeated and combined.

The best part is that none of this is Gemini-specific. Swap the package name and the constructor for almost any other provider, and the shape of the code barely changes: an API key, a model name, a prompt, a reply. Once this pattern is in your hands, moving between providers becomes a five-minute exercise instead of a research project.

Where to go next

The point of this issue isn’t to build something big. It’s to remove the excuse!
The barrier to entry for AI development is now essentially zero. Once that first response comes back, experimenting becomes addictive.

If you take nothing else from this issue, take this: stop treating the first script as a chore to get through before the “real” project starts. The first script is the project. Once you’ve seen a model respond to something you typed yourself, in a file you wrote yourself, with no framework standing between you and the result, you’ll understand why so many developers describe this moment as the one that got them hooked on building with AI in the first place.

So open a folder, drop in a two-line package.json, write your index.ts, and run it. Nothing about this newsletter issue requires a weekend, a course, or a new laptop. It requires about five minutes and a Google AI Studio key. Everything after that first console.log is just you following your own curiosity, one small script at a time.

For the full API surface, models, parameters, streaming, multimodal inputs and more, the official Google Gemini API documentation is the place to explore.

And when you’re ready to go beyond a single script and build real, production-grade AI features into a modern front end, my book walks you through it end to end: Building AI-Powered Apps with Angular.

Fabio Biondi | Google Expert
Follow me on LinkedIn

This Week in the News

🔓 The npm Worm That Plants a Dead Man’s Switch on Your Machine: A worm hit keyv, cacheable, and flat-cache via a compromised maintainer account, and it plants autostart hooks in .claude/.vscode and even a dead-man’s-switch that fires on token revocation. If you’re on eslint, you’re likely affected through the dependency chain. Pin to pre-compromise versions now.

🖥️ Cloudflare Says Your Agent Deserves Better Than a Container: Cloudflare’s answer to “every agent needs its own container”: a shared filesystem where agents pick between a cheap isolate or a full Linux container per task, instead of paying container tax for everything. Worth a look if you’re building agent infra.

🪟 Microsoft Just Killed the Native Addon for Windows APIs in Node: Call native Windows APIs (notifications, on-device AI, clipboard) straight from JS in Electron, no C++ bridge required. Codegen turns Windows metadata into JS wrappers directly. Handy if you’ve been dreading a native module.

🎣 A Security Expert Almost Fell for His Own Company’s Product: Eric Lawrence nearly reports a legit new Cloudflare product as phishing, because it followed every anti-pattern phishers use. The takeaway: if an expert can’t tell your flow from an attack, the flow’s the problem.

Beyond the Headlines

🌐 How a 15-Year-Old CDN Survived Its Own Success: cdnjs moved off a six-year-old GCP pipeline onto Cloudflare’s own Workers/Workflows/R2 stack, forcing Cloudflare to raise its own platform limits along the way. Good read if you’re evaluating Workflows for long-running jobs.

💰 The GPU Math Most Teams Get Wrong: Crossover point is ~2M tokens/day; below that, hosted APIs win because the MLOps hire costs more than the GPUs. Send to anyone convinced buying hardware saves money.

🐚 The JavaScript Comment Syntax Nobody Uses (But Is Actually in the Spec): Short video on hashbang comments (#!) — yes, they’re really in ECMAScript.

🍔 DoorDash Built a CLI That Skips the “Are You Sure?” Prompt: dd-cli skips the human-confirmation step DoorDash’s other AI surfaces keep. The “read ≠ write ≠ spend” framing is worth stealing regardless of what you think of the stunt.

📐 We Solved Centering a Div, Then Browser Sidebars Ruined Everything: place-items: center centers your div in the webview, not the window, and fixing that needs pointer events since Chromium won’t tell you the split. A fun precision-layout rabbit hole.

🎨 The CSS Feature Everyone Wants and Nobody Can Ship: Anchor Positioning is both the most-wanted feature and the most avoided due to browser support. Also: CSS remains the one part of web dev resisting AI-generated code (28% average).

Developer Toolbox

🖼️ React Image Editor - A Full Photoshop-Lite for React, Minus the Bloat: Crop, resize, filters, draw, shapes, stickers, plus an optional AI Assistant. Works in RSC out of the box, tool rail is fully configurable.

🔐Varlock - .env Files That Won’t Leak to Your AI Agent: Drop-in dotenv replacement built for the agent era: agents read your .env.schema for context but never see real secret values, and its credential proxy swaps in real values only at the network boundary.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the expert: Haimantika Mitra

Haimantika Mitra wrote this issue’s featured article on Designing AI Apps Around Two Planes: Control and Data. She is a Senior Developer Advocate by profession, working in core AI and infra and is also currently doing her master’s in AI from Georgia Institute of Technology, Atlanta. She has written an ebook on How to DevRel for Startups and has been writing a number of other technical articles on core AI, GPU, and also developer experience.

If you have shipped an AI feature, you have probably run into this already. You want to reword a prompt, but since the prompt lives inside your application code, changing it means a pull request, a review, and a full deploy. A wording tweak now moves at the speed of your whole release pipeline.

This is common enough that it has become its own genre of blog post. “Why your prompts don’t belong in Git.” “Prompt templates as configs, not code.” The advice is consistent: pull the prompt out of the codebase so you can change it without redeploying, and teams back this up in practice by fetching prompts from a registry at runtime instead of hard-coding them.

This is one example of a much larger idea, and once you see the larger idea, a lot of AI design decisions get easier to reason about.

The larger idea is separating the control plane from the data plane.

In this issue, we will look at why the usual “one big blob” design gets painful, what the two planes actually are, and how to decide what belongs where. We will also look at a recent research paper that pushes the idea further than most teams do.

But before we get into it, here’s a glimpse of what awaits you further in the issue:

• 💸 OpenAI Slashes GPT‑5.6 Prices, Adds Fast Mode

• ▶️ The Creator of TypeScript Shows Off TypeScript 7

• ✂️ The new rules of context engineering for Claude 5 generation models

• 🔍 How an AI Agent’s Curiosity Cut Heap Size by 60%

• 🗺️ MapLibre GL JS Docs

First, let’s define what it means

The words “control plane” and “data plane” come from networking. Let’s understand this with the help of a kitchen:

Think of a restaurant. There is a head chef who decides the menu, writes the recipes, and says which dishes are allowed tonight. Then there are the line cooks who take an order and actually cook the food, fast, the same way every time. The head chef is the control plane who makes decisions. The line cooks are the data plane. They do the work, and the food (your data) passes through their hands.

The head chef does not need to touch every plate to do her job. And the line cooks do not need to re-invent the recipe for every order. The kitchen works because those two jobs are separate.

Now map that back to an AI app.

• Control plane = the decisions. Which model to use, what the prompt is, which tools the agent may call, what the guardrails are, and how you measure if a change was good (your evals).

• Data plane = the work. The actual inference call, the retrieval, the token streaming, the request and response that carry real user data.

The “one big blob” problem

When you ship your first AI feature, mixing the two feels natural. It is all just one function. Here is roughly what that looks like:

^{Figure 1: One handler doing everything, decisions and data movement are tangled together.}

It works for a while, until it doesn’t. Here is where it starts to hurt:

1. You can’t answer “where did the data go?”

Because the prompt, the model keys, and the user’s documents all live in the same code path, the user’s data flows to every vendor in that path. It happened, because there was no line to stop it.

2. Every tiny change is a full deploy.

Want to A/B test a new system prompt? Swap a model? Turn off a tool that is misbehaving?

If those decisions live inside your handler code, you cannot change them without shipping code. A one-line prompt tweak becomes a pull request, a review, and then a deployment.

3. One hiccup takes the whole thing down.

Say your prompt-config service has a bad minute. In a blob design, your inference cannot run without it, so your AI feature goes dark, even though the model provider was up the entire time.

This should feel familiar if you read our earlier issue on service discovery. The same lesson applies here: a system that can’t survive one piece going wobbly is a system that will page you at 2 a.m.

Quick checkpoint before we fix it: if you cannot describe, in one sentence, which parts of your AI feature are “decisions” and which parts are “moving data,” you are probably in blob territory.

That is okay. Let’s draw the line.

Drawing the line

Kubernetes did this. Service meshes did this. Software-defined networking did this years ago. The decision-making layer is kept separate from the layer that carries traffic, so you can change one without disturbing the other. Here is the same idea for an AI app.

^{Figure 2: Two planes, one boundary. Decisions live on top and get handed down as config. User data lives at the bottom and never flows up.}

The boundary is the important part, so let’s be understand about how it behaves:

• Decisions flow down. The control plane hands the data plane a set of instructions: use this model, this prompt version, these allowed tools, these limits. It hands down config, not data.

• Data does not flow up. The data plane can send metrics up (latency, token counts, “did the guardrail trip”) but not the raw user content. This one rule shrinks your privacy blast radius dramatically. Now the answer to “where does the data go?” is short: it stays in the data plane.

That is the whole design. Two boxes and a rule about which direction things are allowed to travel.

You can now change a prompt, add a model, or tighten a guardrail entirely in the control plane, without redeploying the thing that serves users. The good news is you do not have to build any of this from scratch. A lot of it already exists as off-the-shelf infrastructure, and the industry has quietly converged on the same two-plane language.

For the “which model, with what limits” decisions, that infrastructure is the LLM gateway. Tools like LiteLLM (open source, self-hosted), Portkey, Kong AI Gateway, and Cloudflare AI Gateway sit between your app and the model providers and handle routing, failover, caching, rate limits, and cost tracking, without you touching application code. Several of them describe themselves, in exactly these words, as a control plane for your AI traffic. Some even split their own product into a managed control plane and a data plane that runs inside your network, which is the whole idea, shipped.

For the “what is the prompt” decisions, the equivalent is a prompt registry: PromptLayer, Braintrust, LangWatch, or MLflow’s prompt registry, among others. Your app fetches the active prompt version at runtime, and prompt edits become an operational change instead of a code release.

Research says: keep the LLM out of the hot path

Here is where it gets interesting, and where a recent paper changed how I think about this. Most of us instinctively put the LLM in the data plane. It is the thing doing the work, so of course it goes on the request path, right?

A 2026 paper on Research Square, “LLM-driven control-data plane separation for zero-intrusion TCC transactions in legacy microservices,” argues for the opposite, and it is a genuinely clever inversion.

The authors put the LLM in the control plane, and they run it offline. In their design, the model reads the system’s API specifications and reasons about them once, ahead of time, to produce a set of plain, deterministic rules. Then the data plane is just a fast proxy that applies those rules on every request, no model call in the loop.

^{Figure 3: The LLM does the slow, smart thinking once, offline.}

Why is this smart? Because it isolates the unpredictable part of your system from the part that has to be fast and reliable. The paper reports that keeping the model off the real-time path lets the online proxy run with constant, predictable latency, precisely because a generative model, which is nondeterministic by nature, never runs during a live request.

You do not have to adopt their exact setup to steal the lesson:

The nondeterministic thing belongs in the control plane. The hot path should be as predictable as you can make it.

Sometimes your product genuinely needs the model live in the data plane, a chat assistant, for example, has to call the model per turn. Put the model on the hot path only when the feature truly needs it, and keep everything you can (routing, config, guardrail rules, tool choices) up in the control plane where it is cheap to change and safe to reason about.

Make the boundary fail gracefully

One more design detail, because this is where real systems earn their keep. What happens when the control plane goes down?

If you designed the boundary well, the answer is: not much, for a while. The data plane should keep a cached copy of its last-known-good instructions and keep serving with them.

Think of it like the line cooks having tonight’s recipes printed and taped to the wall. If the head chef steps out, dinner service does not stop. The cooks keep making the dishes they already know. They just cannot get new recipes until the head cook is back.

So a control-plane outage should mean “we cannot change decisions right now,” not “the product is down.” That is a graceful degradation, and it is only possible because you separated the two planes in the first place.

What this does not fix

I want to be honest here, because separation is a design principle, not a magic.

• It does not make your model correct - A clean data plane will still happily stream a confident, wrong answer. Separation controls where things run, not whether the output is any good. Your evals in the control plane are what catch that.

• It adds a moving part - You now have a boundary to maintain, config to version, and a cache to keep fresh. For a prototype, a blob is genuinely fine, and most gateway guides say the same thing: skip the extra layer until you actually need it.

• It does not draw the line for you - Some things sit awkwardly in the middle, and retrieval is the classic example. A useful rule of thumb: if changing something alters your app’s runtime behavior, routing, or decisions without needing a code change, it probably belongs in the control plane. If it is tightly bound to application logic, leave it in the code.

• A stale cache can bite - If the data plane serves last-known-good config for too long during a control-plane outage, you might be running a prompt or a policy you meant to retire.

Where to get started

You do not need to re-architect anything on Friday afternoon. Try this instead:

Open your main AI handler and read it top to bottom. For each thing it does, write one word next to it: decision or data.

By the time you reach the bottom, you will see the tangle from Figure 1 and the line will almost draw itself. The first thing you pull out is usually the prompt or the model choice, because those are the ones you change most often and want out of your deploy pipeline first.

Quick summary

• Control plane = decisions, data plane = work. Which model, which prompt, which tools, and your evals are decisions. Inference, retrieval, and streaming are work.

• Make the boundary one-directional. Config flows down. Metrics can flow up. Raw user data never flows up.

• Keep the nondeterministic thing off the hot path when you can. The research is a strong nudge here: let the LLM do slow, smart work offline and hand the live path boring, deterministic rules.

• Design for graceful failure. A control-plane outage should mean “no new decisions,” not “product down.”

• Start by labelling. Tag each line of your handler as a decision or data.

Separation of concerns is one of the oldest ideas in software, and AI apps did not escape it. The names are new, but the instinct is the same one you already trust everywhere else in your stack: keep the part that decides separate from the part that does.

Some resources that you can refer to:

• LLM-driven control-data plane separation for zero-intrusion TCC transactions in legacy microservices - Research Square, 2026 (the “put the LLM in the control plane” paper)

• Arize, Prompt templates as configs, not code (the config-vs-code rule of thumb)

• Braintrust, What is prompt management? (why decoupling prompts from releases matters)

This Week in the News

💸 OpenAI Slashes GPT‑5.6 Prices, Adds Fast Mode
Luna is now 80% cheaper and Terra 20% cheaper, and Sol gets a new Fast mode running up to 2.5x faster at double the price, replacing Priority Processing. The number that actually matters: on Agents' Last Exam, Luna reportedly beats Fable 5 at nearly 99% lower cost per task. This is OpenAI betting that most agent workloads don't need frontier reasoning at every step. If you're still running multi-step pipelines on older models, this is worth a cost audit now.

🔧 Cloudflare Workers and Hyperdrive with SvelteKit: A solid walkthrough of wiring SvelteKit into Cloudflare Workers, including the “gotcha” that killed the author’s first deploy (drop wrangler types --check from your build script, it’s more trouble than it’s worth). The real value here is the Hyperdrive setup and per-request connection pattern via hooks.server.js, required reading if you’re putting a database behind Workers instead of a traditional long-lived server.

🧠 Kimi K3 Architecture Notes: Raschka’s rapid-fire breakdown of the now-largest open-weight model (2.8T params) is the fastest way to understand where LLM architecture is heading: LatentMoE, Kimi Delta Attention, and a full switch to NoPE with zero RoPE layers anywhere. Notably it’s the first frontier model to ditch positional embeddings entirely rather than mixing NoPE and RoPE, worth a skim even if you don’t care about the benchmarks.

✂️ The new rules of context engineering for Claude 5 generation models: Anthropic cut over 80% of Claude Code’s system prompt for newer models and shares why: rigid rules and repeated examples that used to compensate for weaker judgement now just constrain a model that’s gotten good enough to reason about tradeoffs itself. If your CLAUDE.md or agent prompts are still stuffed with defensive instructions “just in case,” this is a nudge to trim them back and lean on progressive disclosure instead.

🛡️ npm publish-time malware scanning and dual-use metadata: npm now scans every package before it’s installable, adding a ~5-15 minute publish delay, annoying if you have CI that assumes instant availability, but a genuinely good supply-chain move. The more interesting bit is the new contentPolicy/DISCLOSURE requirement for legitimate security tooling that looks malware-ish to scanners; if you maintain anything security-adjacent, go check whether you need to add this metadata before you get auto-blocked.

🪟 Dynamic API projections for Node.js: Microsoft’s new WinRT projection lets Electron/Node apps call native Windows APIs (on-device AI like Phi Silica, rich notifications, clipboard, sensors) straight from JS, no C++ addon or node-gyp required. It’s a genuinely clever “codegen from metadata” approach, though one commenter’s dig about Teams eating 1.5GB of RAM is a fair reminder that easier native access doesn’t fix Electron’s fundamental appetite.

Beyond the Headlines

▶️ The Creator of TypeScript Shows Off TypeScript 7: Anders Hejlsberg walks through the Go-ported, natively-compiled TypeScript 7 compiler, and the numbers are hard to ignore: Slack cut CI type-checking from 7.5 minutes to 1.25, Vanta saw up to 9x faster builds, and language-server crashes dropped over 60%. If you haven’t upgraded yet, this is the demo that’ll convince you to stop putting it off.

💸 How I Stopped Running out of Tokens: A refreshingly concrete rundown of tools and habits (rtk for compressing CLI output, Caveman for stripping filler from responses, auditing bloated CLAUDE.md files) that actually moved the needle on Claude Code spend. The CLAUDE.md audit story alone, converting always-loaded @ references into conditional ones, is worth stealing for any team drowning in context bloat.

⚙️ GitHub is the wrong shape for this new world: Depot’s CEO argues that PR-based, human-paced collaboration is now the actual bottleneck now that agents generate code at machine speed, and that we need to think of software delivery as infrastructure primitives (source control, execution, artifacts, identity, policy) rather than a better pull request. Self-serving coming from a CI vendor, sure, but the underlying question, who reviews and owns code when everyone in a company can generate it, is one every eng org is going to have to answer soon.

🧩 The Absolute State of Management: Alex Russell’s latest is a pointed jab at “state management” as a term that only exists because React made simple UI updates needlessly hard. Bracing if you’ve built your career on Redux/Zustand-style tooling, but a useful gut-check on how much complexity in modern frontend is self-inflicted rather than essential.

🛠️ TanStack is Doing What?: Tanner Linsley drops a “big change” for TanStack live with guests, no spoilers here, but given TanStack’s footprint across Query, Router, Start, and DB, whatever this is will likely ripple through a lot of stacks. Worth watching live rather than waiting for the recap thread.

🔍 How an AI Agent's Curiosity Cut Heap Size by 60%
A stray Ruby warning about redefining object_id, filtered out during a routine spec run, turned into a real find: opentelemetry-instrumentation-aws_sdk's use_all config was force loading all ~200 services in a legacy aws-sdk v2 gem just to instrument a handful. One patch dropped loaded services from 220 to 0, classes in the VM by 60%, and boot time by 36%. The lesson: pointing an agent at "diagnose this" for something adjacent to your task is cheap enough to do constantly now. Worth checking your own boot logs if you're on an old aws-sdk v2 pin with OTel enabled.

Developer Toolbox

🗺️ MapLibre GL JS Docs: The open-source, WebGL-based Mapbox alternative just shipped v6 as ESM-only, which means bundler setup now needs explicit worker-URL wiring (Vite’s ?worker&url, not plain ?url, the naive version silently breaks production builds). If you’re on Mapbox and dodging their license/pricing, or upgrading from MapLibre v5, the migration guide and per-bundler snippets here will save you a debugging session.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the expert: Jeremy McEntire

For twenty-five years, Jeremy has built and led engineering teams at Intel, Twilio, and startups both scaled and failed. He currently leads engineering at Wander, with experience ranging from ten-person teams to organizations large enough to need committees to approve the committee structure. Alongside that work, he writes about the structural patterns behind organizational dysfunction, what he calls the legibility trap, the fiduciary trap, the context trap, and the scale trap, drawn from failure modes he’s seen firsthand across startups, scale-ups, and public companies. His focus is helping leaders see their organizations as systems rather than slogans, and build structures that respect the real cognitive and communication limits of the people inside them.

There’s a strange thing happening on engineering teams right now, and most people who are living through it can’t quite name it. AI coding tools have made writing code faster than it has ever been. Ask for a function, a component, an entire feature scaffold, and it appears in seconds, syntactically correct and reasonably named. And yet a lot of teams that have adopted these tools aggressively are not shipping meaningfully faster. Some are shipping slower. The output looks like progress. The delivery numbers tell a more complicated story.

Earlier this year, a research group ran one of the first controlled studies on whether AI tools actually speed up experienced developers. They took sixteen seasoned open-source contributors, people with years of experience on codebases they knew intimately, and had them complete real tasks with and without AI assistance. Before starting, the developers predicted the tools would make them about twenty-four percent faster. Afterward, they reported feeling roughly twenty percent faster. When researchers measured the actual time taken, the developers had been nineteen percent slower.

That gap between what people believed and what actually happened is the real story here, more than the slowdown itself. Sixteen experienced engineers, working on projects they understood well, came away convinced the tools had helped. They hadn’t, and nobody could tell from the inside. That’s worth sitting with, because it points to something the industry has quietly misunderstood about what software engineering actually is.

Before we get into the details, here’s a TL;DR of what’s in store for today’s issue:

• 🔓 Reddit Has Decided That Plain HTML Is Unsafe

• 📅 Angular Is Moving to Yearly Major Releases

• 🕵️ North Korean Hackers Hid Malware Inside Flag Emoji SVGs

• 🍽️ Loop Engineering, Explained with Dirty Dishes

• 🌸 Petals: Run Massive LLMs at Home, BitTorrent-Style

• 🎨 Four Frontier Models “Draw” the Mona Lisa with Virtual Colored Pencils

Generating and Verifying Are Not the Same Job

Writing code and checking whether that code is right are two very different mental activities. Writing code is generative and sequential, a stream you can ride. Checking code means holding an entire system in your head at once, a landscape you have to survey piece by piece. Making the stream move faster doesn’t shrink the landscape. It just means there’s more of it to cover.

This is why code review times and pull request sizes have grown substantially at organizations with heavy AI adoption. The bottleneck didn’t disappear when code got cheap to produce. It moved, and the new one is more cognitively demanding than the old one.

None of this means the tools are bad or that adopting them is a mistake. It means they behave like an amplifier rather than a fix. Teams with strong habits already in place tend to get genuinely faster with AI in the loop. Teams without those habits tend to get faster at accumulating problems. The tool doesn’t install discipline. It reveals whether you had any to begin with.

Context Sets the Ceiling, Not the Model

There’s a second, quieter shift happening alongside this one, and it has to do with what actually determines whether an AI produces good output in the first place. The instinct most people have is that better output comes from a better model. That’s only partly true. An AI system’s output is bounded above by the quality of the information you hand it, not by how capable the underlying model is. A model can’t produce output more correct than its context permits, no matter how good it is underneath.

This has a practical implication that’s easy to miss: writing good prompts isn’t really about phrasing tricks. It’s closer to what a good manager does when onboarding a new hire, deciding what someone needs to know first and what would just create noise if you dumped it all at once. Too little context and the output is generic. Too much and the important signal gets buried. Getting this right is a skill, and it’s one that’s going to matter more over the next few years, not less.

Judgment Belongs in the Pipeline, Not Just the Reviewer’s Head

The same logic applies to how teams check whether code is actually good. Most code review today is advisory: someone reads a pull request and forms an opinion. Two competent reviewers can look at the same code and reach different conclusions, and when they disagree, the outcome usually comes down to seniority or persistence rather than anything measurable about the code itself.

The alternative is mechanical verification: tests that pass or fail, type checks, contracts that specify exactly what a function should take in and return. These don’t get tired and don’t approve something because they like the person who wrote it.

As AI generates a larger share of a team’s code, leaning harder on mechanical checks rather than a gut read of whether something looks right is quickly becoming less of a nice-to-have and more of a requirement for staying sane.

What to Actually Do With This

A few things worth carrying into your next sprint. First, don’t confuse the feeling of speed with the fact of it. If a team’s velocity metrics aren’t moving even though everyone feels busier, the AI usage is probably worth auditing rather than doubling down on. Second, spend real effort on what you feed these tools before a task starts. A well-scoped paragraph of context will do more for output quality than switching models or fiddling with settings. Third, wherever possible, replace a subjective judgment call with a test, a type, or a contract that can answer the question without a person having to weigh in at all. None of this is about resisting these tools. It’s about using them with your eyes open to what they’re actually good at, and what they were never going to fix.

That question, what these tools are actually changing and what they’re leaving untouched, is exactly the kind of thing worth putting to someone who’s spent real time studying it closely. We put a few questions to Jeremy, the man behind some of the research and thinking above, and the answers are worth reading in full:

Q: You’ve made a point of writing about the underlying “physics” of engineering rather than about specific tools. Why take that approach?

Technology accelerates, and the rate of change is itself changing. Anchoring your career to a specific tool means re-learning your job every eighteen months and never getting better at it. The principles underneath haven’t moved in decades. They were true before the tools existed and they’ll be true after the tools are gone. Betting on a technology is a bet with an expiration date. Betting on principles isn’t a bet at all.

Q: You’ve argued that writing code was never really the hard part of the job. What do you mean by that?

Every industry walks the same road: bespoke craft, then efficient production, then automation. Economic pressure does not negotiate. But automation doesn’t destroy the craft, it relocates it. The craft doesn’t die. It moves from vocation to avocation. Writing code was never the hard part. It was just the part that took the longest, and that’s a different thing entirely.

Q: Why do you think apps built by “vibe coding,” without much engineering discipline behind them, tend to fall apart once they hit real users?

An AI solves the problem you put in front of it. Engineering is everything you didn’t put in front of it: the constraints, the trade-offs, the edge cases, the failure modes. A non-engineer can vibe-code a flawless happy path, and the demo will be genuinely impressive, because a demo is the happy path. Then reality shows up, and reality has never once taken the happy path.

Q: A lot of people assume more context always leads to better AI output. You’ve pushed back on that. Why?

Working memory is finite, for people and for models alike. Flood it and you get exactly what you’d get from an overloaded engineer: dropped constraints, forgotten requirements, confident mistakes. But the fix isn’t a terse prompt. My research points somewhere else: induced understanding beats instruction. Knowing where to assert an invariant, where to bind a constraint, and where to leave the choice free is engineering judgment applied to the prompt itself. Tell a model what to do and it complies. Help it understand why it matters and it decides well.

Q: Why do mechanical checks, like tests and type contracts, matter so much more now than they used to?

We invented tests and types because no human can reliably hold every scenario and every edge case in their head at once. That limitation wasn’t a personal failing, and it isn’t unique to us. An AI forgets a constraint the same way you do, on the same kind of Tuesday. Signatures, argument types, return types, executable contracts, these are safeguards that maximize confidence while minimizing what you have to carry. A gate doesn’t get tired, doesn’t get rushed, and doesn’t approve your PR because it likes you.

Q: You talk about “grokking” a lot, the idea of intuitive understanding built through experience. How does that concept survive in a world where AI writes so much of the code?

To grok is to understand intuitively, and it’s bought only one way: exposure, repetition, experience. Engineers will not grok the same things in ten years that they grok today. They’ll grok how AI fails, how to shape a prompt so the result lands, how to orchestrate several models toward one end. That’s not a loss of depth. It’s depth pointed somewhere new. People go on knowing what’s necessary to know. What changes is what’s necessary.

Q: As generating code gets cheaper and cheaper, who do you think actually comes out ahead?

Consider writers. The authors of profound work aren’t losing sleep over AI. The ones who should worry are the ones whose prose is everywhere and whose names are nowhere. The masters aren’t competing with the machine, they’re not in the same space as the machine. Engineering is identical. The truly elegant code of a master isn’t what AI replaces, and it was never an economically viable profession for the plurality anyway. An engineer who knows little of their craft’s nuance finds little purchase on a force multiplier. An engineer who understands the principles underneath watches their value compound.

If you want to learn more about Jeremy’s book, check it out here.

This Week in the News

🐦 Fable Found a 15-30% Memory Improvement in Turbopack, Nearly Autonomously: Vercel’s Guillermo Rauch shares a striking “holy s***” moment: Claude Fable 5 discovered a 15-30% memory efficiency win in Turbopack’s Rust codebase largely on its own, days after a different model reportedly surfaced novel vulnerabilities in heavily audited code. Rauch’s favorite AI progress metric right now is “WTFs per day,” and it’s climbing. Worth a skim if you want a gut-check on how fast agentic coding is actually moving, straight from someone shipping production infrastructure.

🔓 So Reddit Has Decided That Plain HTML Is Unsafe: Old Reddit now requires a login, officially “for safety,” and this post methodically dismantles that claim: New Reddit loads five times more data, still gets scraped, and mostly just adds a heartbeat ping every half second while you scroll. The real story, as the author bluntly puts it, is that Reddit wants to protect its own data from being scraped for free, not protect users. A satisfying, technical takedown of corporate security theater.

⚡ Google Ships Gemini 3.6 Flash, 3.5 Flash-Lite, and a Cyber-Focused Model: Three new Flash-tier models aimed squarely at agentic workloads: 3.6 Flash cuts output tokens by 17% while improving coding and computer-use benchmarks, 3.5 Flash-Lite hits 350 tokens/second as the cheapest option in the lineup, and 3.5 Flash Cyber is a specialized model gated behind a government/trusted-partner pilot for vulnerability hunting. The gated cyber model is the detail worth sitting with, since it’s a tacit admission that these capabilities are now too sharp to hand out freely.

🚨 OpenAI and Hugging Face Detail a Model That Hacked Its Way Off the Leash: During an internal cyber-capability evaluation run without production safety filters, OpenAI’s models chained a zero-day, escalated privileges, and broke out to the open internet purely to cheat a benchmark, then used that access to pull real credentials from Hugging Face’s production systems. Both companies are framing this as a wake-up call for the industry rather than burying it, which is the right instinct, but the details here are genuinely unsettling regardless of the framing.

📅 Angular Is Moving to Yearly Major Releases, Starting with v23 in June 2027: The community has wanted this for years, and the stated rationale explicitly name-checks agentic workflows: longer major cycles mean more API stability for AI coding tools, while features keep shipping in minors as before. The most interesting pushback in the thread isn’t “why change” but “what does slower major cadence signal about investment,” especially with fast-moving experimental features like WebMCP in play.

🕵️ North Korean Hackers Hid Malware Inside Flag Emoji SVGs: A DPRK-aligned group posed as recruiters, sent developers a “coding challenge,” and hid a four-stage credential-and-wallet stealer as Base64 fragments buried in comments inside ordinary-looking country flag SVGs. Zero antivirus vendors caught it. If you or your team ever do take-home coding tests from strangers on Slack or Discord, this is the specific, current shape of that risk.

Beyond the Headlines

🐘 The Startup’s Postgres Survival Guide: Hatchet’s co-founder distills two years of production Postgres scars into one document covering schemas, indexes, the query planner, autovacuum, bloat, and advanced tricks like FOR UPDATE SKIP LOCKED and partitioning. It’s dense but genuinely practical, the kind of reference you bookmark rather than read once. Bonus points for the honest aside that if Claude is writing all your queries, some of this may already be handled for you.

🍽️ Loop Engineering, Explained with Dirty Dishes: The clearest plain-English explainer yet of the “loop engineering” trend making the rounds: the difference between an AI that scrubs a plate once and hands it to you dirty, versus one that checks, adjusts, and knows when to ask for help. The three questions every loop needs to answer (what does “clean” mean, when do you stop, when do you escalate) are a genuinely useful mental model for evaluating any agentic tool, not just this one.

🎨 Four Frontier Models “Draw” the Mona Lisa with Virtual Colored Pencils: A delightfully specific benchmark: give four models the same colored-pencil toolset and a blank canvas, then watch how differently they work. Grok flailed, Gemini over-reviewed and then regressed, GPT-5.6 Sol was the clear favorite, and Claude Fable 5 landed second on quality at roughly 20x the cost and time of the others. Every model, notably, kept editing itself past its own best result, which says something uncomfortable about self-review loops in general.

🎯 OpenAI Measures Whether Models Chase the Grader Instead of the Truth: A clever methodology paper: train two copies of the same model on opposite fictional beliefs about what a grader rewards, then see which one wins when it conflicts with what the user or developer actually wants. The finding is the uncomfortable part: reward-seeking behavior measurably increased over the course of RL training, and a model’s honesty in safety evaluations depended on what it believed was being graded. Dense but important if you care about whether alignment evaluations can be trusted.

🔒Handling Concurrency on the Web with the Web Locks API: A solid walkthrough of a genuinely underused browser API: navigator.locks lets multiple tabs or workers coordinate access to a shared resource without you hand-rolling your own synchronization logic. If you’ve ever had two open tabs quietly corrupt the same IndexedDB store, this is the fix you didn’t know shipped years ago.

Developer Toolbox

🌸 Petals: Run Massive LLMs at Home, BitTorrent-Style: A distributed inference network where you load a slice of a large model (Llama 3.1 405B, Mixtral 8x22B, BLOOM 176B) and lean on other volunteers serving the rest. It’s slow by API standards, a few tokens per second, but it’s a fascinating glimpse at community-run infrastructure for models too big for any one consumer GPU.

🎨Color.js: Serious Color Science for the Web: Built by two editors of the CSS Color spec, this library does real gamut mapping instead of naive clipping, supports every CSS Color 4 space (Lab, OKLCh, Display P3, and more), and stays dependency-free. If your color handling currently amounts to hex codes and vibes, this is the upgrade path, and it’s already quietly powering Sass and Open Props under the hood.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

The login endpoint is the most visible part of an authentication system, but it is also the simplest. What separates a demo from a production system is everything that happens after the user is logged in: how their session survives, how it ends, how it gets stolen, and how your application behaves when several of those things happen at once.

If you have ever shipped an app where users mysteriously get logged out, where a stolen token stays valid forever, or where a page refresh dumps someone back to the login screen, this article is about the missing pieces. And if your framework manages sessions for you, whether that is Rails, Django, or Laravel, everything below is what that machinery is quietly doing on your behalf, so it is worth seeing it in daylight at least once.

Before we get into all that, here’s a TL;DR of the links you must check out:

• 🕵️ Cloudflare’s Precursor Knows You’re a Bot by How You Move

• 🔨 Good Tools Are Invisible

• 🔁 Loop Engineering: Stop Prompting, Start Designing the Loop

• ⚡Playwright on GitHub Actions: The Setup That Actually Runs Fast

• 🍦Why Vanilla JS

• 💸 The Same TypeScript Costs 73% More Tokens on Claude Than GPT

  Build production-grade apps with Claude Code

  Claude Code can generate code fast, but this workshop shows developers how to make it work reliably inside a real codebase.

  On July 31, Luís Rodrigues and Gabriela de Queiroz will build live and show how to use CLAUDE.md, Skills, MCP workflows, scaffolds, and guardrails to create production-grade apps. You’ll follow the setup step by step and leave with patterns you can apply to your own projects.

  Reserve your seat

Two questions, two status codes

Authentication answers the question of who you are, while authorization answers the question of what you are allowed to do, and they are sequential by nature, because you cannot decide what someone may do before you know who they are. The classic analogy is a building with a keycard system: showing your ID at the entrance is authentication, and whether your card opens the door to the seventh floor is authorization.

This distinction maps directly onto two status codes that developers routinely misuse.

• 401 means the server does not know who is asking, because the token is missing, malformed, or expired. The correct client reaction is a silent token refresh followed by a retry.

• 403 means the server knows exactly who is asking and is refusing anyway. The correct client reaction is a permissions message, with no retry.

The naming is genuinely unhelpful, since 401 is labeled “Unauthorized” when it really means “unauthenticated,” but the convention is universal. When your API is consistent about the difference, your frontend can react intelligently, and when it is not, the client is forced to guess. Guessing in an auth flow is how you end up with refresh loops and phantom logouts.

Statelessness is a trade, not a gift

JSON Web Tokens are popular for a good reason. Because a JWT carries its own claims and a cryptographic signature, any server holding the secret can verify it without touching a database or a shared session store, whether you run one server or fifty behind a load balancer. That property is what people mean when they call JWTs stateless, and it is a genuine architectural advantage.

The part that gets skipped in most tutorials is what statelessness costs you. A signature does not stop being valid because you wish it would, so if a long-lived token is stolen, there is no server-side session to destroy, and the attacker holds a key that works until it expires. A related misunderstanding causes its own incidents: the payload of a JWT is Base64 encoded, not encrypted, so anyone holding a token can read every claim inside it. The signature protects against tampering, never against reading.

The mature answer to the revocation problem is to stop pretending one token can do two jobs.

The database record is the whole point of the second token. By persisting refresh tokens server-side, you reintroduce just enough state to make revocation possible: logging out deletes the record, and “log out of all devices” deletes every record for that user. You trade a little purity for the ability to actually end a session.

Rotation completes the design. Each refresh deletes the old token and issues a new one inside a transaction, so every refresh token works exactly once. If an attacker replays a token the legitimate user already spent, the lookup fails, and a careful implementation treats that as a breach signal and revokes everything for that account. A stolen credential becomes a tripwire instead of a skeleton key.

Where a token lives matters more than how it is signed

Ask an intermediate developer where their tokens are stored and the honest answer is often localStorage, because that is what half the internet’s tutorials demonstrate. It is also the one answer that security reviewers will flag immediately, since anything in localStorage, sessionStorage, or IndexedDB is readable by any script on your page, and a single cross-site scripting vulnerability hands an attacker every token you have saved.

There are three defensible strategies, and choosing between them is a real architectural decision rather than a default.

The hybrid approach is the common sweet spot. Because API requests carry the access token in an Authorization header rather than a cookie, cross-site request forgery is a non-issue for normal calls, and because the refresh cookie is httpOnly, injected scripts cannot read it. Its main cost is that the in-memory token vanishes on page refresh, so the app must silently call the refresh endpoint on load.

The cookie-only strategy trades that residual XSS exposure for CSRF risk, which is manageable but adds infrastructure you must maintain, while the backend-for-frontend pattern keeps tokens out of the browser entirely and suits genuinely sensitive data. The right choice depends on what you are protecting. What is not defensible is making no choice at all and letting a tutorial make it for you.

When your security features attack each other

Here is a failure mode that almost nobody designs for on the first attempt. A user leaves your app open in a tab and comes back twenty minutes later, after the access token has expired. They click something that fires three API calls at once, and the sequence unfolds like this:

1. All three requests receive a 401, and all three independently try to refresh.

2. The first refresh succeeds and, because of rotation, consumes the refresh token.

3. The second and third arrive holding a token that no longer exists.

4. Reuse detection correctly interprets that as a possible attack and revokes every session the user has.

Your two security features, each individually correct, have combined to log out a completely legitimate user.

The fix is small and elegant. The client keeps a single shared reference to any refresh request currently in flight, and every caller that hits a 401 during that window awaits the same promise instead of starting its own, so one network call happens and the queued requests retry with the new token. One guard remains: a 401 from the refresh endpoint itself must never trigger another refresh, or the client deadlocks.

The broader lesson is worth more than the pattern. Authentication is a system, and systems fail at the seams between correct components: rotation is right, reuse detection is right, and concurrent requests are unavoidable, yet together they produce a bug that only appears under real usage. Reasoning about interactions, not just features, is what the intermediate-to-senior transition largely consists of.

The quieter layers

A few remaining decisions round out a production-grade setup, and each one exists to contain the failure of another:

• Hash passwords with a memory-hard algorithm such as Argon2id rather than a merely slow one, because modern GPUs shrug at computational cost but choke on memory cost.

• Rate limit the login, registration, and refresh endpoints, and run the limiter before body parsing so abusive traffic is rejected before the server spends resources on it.

• Cap request body sizes and set cookie flags properly, meaning secure and sameSite in production, so no single oversight becomes an open door.

• Serve everything over HTTPS, because every guarantee above assumes the transport itself is not readable.

The organizing principle is that no single failure should compromise the whole system.

Takeaways

• Treat 401 and 403 as different events with different client responses: one triggers a silent refresh and retry, the other shows a permissions error and stops.

• Use two tokens with different lifetimes, and persist refresh tokens server-side so sessions can actually be revoked.

• Never store tokens in localStorage. Choose deliberately between the hybrid, cookie-only, and backend-for-frontend strategies based on how sensitive your data is.

• Rotate refresh tokens so each works once, and treat reuse of a consumed token as a breach signal.

• Deduplicate concurrent refresh attempts behind a single in-flight promise, or rotation and reuse detection will log out your own users.

• Remember that a JWT payload is readable by anyone holding the token, so it should never contain anything you would not print publicly.

None of this argues against eventually using a managed provider like Auth0 or Clerk, which are sensible choices for many teams. It argues for understanding the machine before you outsource it, so you can evaluate a provider’s decisions instead of inheriting them blindly. The login form was never the hard part. The lifecycle is, and now it is yours.

This article is adapted from the book Full-Stack React, TypeScript, and Node (Second Edition). You can order it there to read more.

This Week in the News

🕵️ Cloudflare’s Precursor Knows You’re a Bot by How You Move: Cloudflare’s new behavioral validation engine watches the entire session, not just a single checkpoint, turning how humans and bots actually interact into continuous detection signals. With AI agents now browsing indistinguishably from people, this feels like the quiet obituary for the CAPTCHA: the future of bot detection is behavioral, invisible, and always on. If you build agents or defend against them, this is required reading.

🎨 Paper Shaders Is Now Free and Fully Open Source: Zero-dependency canvas shaders for React and vanilla JS, and now completely free. Beautiful, GPU-driven backgrounds and effects usually mean pulling in Three.js and a weekend of GLSL headaches; this gives you the eye candy with none of the dependency weight. One of those rare libraries where the demo page alone will sell you.

🖼️ Takumi 2.0: JSX to Images, No Browser Required: Takumi renders JSX and HTML straight to images using a single Rust binary, and this major release squares up directly against Satori and next/og for JSX-based social card rendering. Skipping the headless browser entirely means faster, cheaper OG image generation with fewer moving parts. If your social cards are currently rendered by a Chromium instance you resent paying for, take a look.

Beyond the Headlines

🔁 Loop Engineering: Stop Prompting, Start Designing the Loop: Addy Osmani argues that prompting skills are becoming obsolete; the real skill is designing the system that prompts your agents for you. He breaks it into five building blocks (automations, worktrees, skills, connectors, sub-agents) plus persistent memory, and shows how both Claude Code and the Codex app now ship all of them natively. Refreshingly, he stays skeptical about token costs, which is exactly the caveat this trend needs.

💸 The Same TypeScript Costs 73% More Tokens on Claude Than GPT: A genuinely eye-opening measurement study: because every vendor tokenizes differently, the price per million tokens on the rate card tells you almost nothing about your actual bill. The same TypeScript file becomes 1,178 tokens on Anthropic’s newest tokenizer versus 681 on GPT’s o200k, and Anthropic’s tokenizer change added roughly 30% more tokens at the same list price. If you’re comparing model costs by pricing page alone, you’re doing it wrong.

⚡ Playwright on GitHub Actions: The Setup That Actually Runs Fast: Slow Playwright CI is almost never your test suite’s fault. It’s the default workflow re-downloading 300 to 500 MB of browsers on every push and running tests on a single worker. This walkthrough fixes both with caching and parallelism, gets a real pipeline well under five minutes, and, crucially, tells you when sharding is actually worth it (later than you think).

🔨 Good Tools Are Invisible: The creator of Odin takes aim at a habit we all recognize: dressing up a tool’s shortcomings as a fun puzzle and then evangelizing the puzzle. His test is brutal and correct: feeling clever is not the same as being productive, and the honest metric is wall-clock time. Guaranteed to mildly offend at least one vim devotee on your team, which is precisely why you should send it to them.

🧵 Node.js Worker Threads in Production: Spawning a worker thread is one line of code; making it production infrastructure is everything else. Inngest documents the unglamorous reality: designing the postMessage protocol as a real API boundary, proxying callbacks, shipping the worker as a build artifact, capping crash-respawn loops, and treating shutdown as a drain protocol. This is the article the official docs should link to.

🍦Why Vanilla JS: A contrarian defense of building for the web without frameworks, arguing the problems frameworks solve can be handled with plain JavaScript and a little discipline. Whether you nod along or grind your teeth, it’s a useful provocation: the strongest counterargument (frameworks are really about teams agreeing on solutions, not solving problems) came from the ensuing Hacker News debate, and both sides are worth your time.

Developer Toolbox

🧠 LiteRT.js: Google’s High-Performance Web AI Inference: Google brings its native on-device inference runtime to the browser, letting you run .tflite models locally with WebAssembly, GPU acceleration via ML Drift, and WebNN support on the way. It’s positioned as the serious evolution of TensorFlow.js, swapping JavaScript kernels for the real optimized runtime. Local inference means zero server costs, better privacy, and latency your users will actually notice.

🧹 FracturedJson: JSON Formatting Humans Can Actually Read: A JSON formatter that hits the sweet spot between minified chaos and pretty-printed sprawl: human-readable but fairly compact. If you regularly stare at big lumps of JSON, this makes them genuinely pleasant to scan, and it even tolerates non-standard JSON comments. A small tool that removes a daily annoyance, which is the best kind.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

That assumption falls apart under scrutiny, and the reason is worth spelling out, because it changes what “good prompting” actually requires the moment your output has to run in production instead of sit in an inbox.

Before we get to that, here’s a look at what’s making news this week:

• 🚀 TypeScript 7 Just Made Your Compiler 10x Faster

• 🦀 Bun Rewrote Its Entire Codebase in Rust Using 64 Claudes in 11 Days

• ⚡ Vite+ Goes Beta

• 🧭 Safari Ships an MCP Server

• 🧙 Working With AI: A Concrete Example

• 🏗️ Apps After Agents

• 🎤 24 Tips for Giving S-Tier Demos

The Same Advice, Written for Different Stakes

Sebastian Huelswitt’s AI for Anyone: The Beginner’s Guide to AI is a fair representative of the genre this assumption comes from. It’s built for someone who has never opened ChatGPT and just wants to stop feeling behind — pick a tool, write a first prompt, learn to ask more clearly, use the output for everyday things like emails or generated images. As a genre, these guides have gotten genuinely good at teaching the one mechanic that matters most to their audience: a specific prompt beats a vague one. That advice isn’t wrong. It’s calibrated for a world where a mediocre first draft costs you a few minutes of editing, not a production incident.

What Specificity Means When the Output Is Code

For a developer, “specific” stops meaning “clear about tone and topic” and starts meaning something much narrower and more technical: which framework and version, which components already exist and shouldn’t be reinvented, which validation approach the rest of the codebase already uses, what the accessibility bar is, where the edges of scope sit. Leave any of that out and you get something that runs but doesn’t belong: a form that duplicates three components you already have, ignores your linting rules, or quietly pulls in a dependency nobody approved.

^{Fig. 1 — Two prompts asking for the same login form. One is general enough for a beginner’s guide. The other names a framework, an existing component library, a validation approach, and an accessibility requirement — the difference between an answer and something you can actually merge.}

None of this is exotic information. It’s the same context you’d put in a ticket or hand to a contractor on their first day. The skill was never a secret syntax. It’s the discipline of writing down context a beginner prompt is allowed to skip.

The Distance Between Confidence and Correctness

You’ve likely run into this without naming it. The output looks put-together. It compiles. It might even pass a quick manual check. Then a reviewer, a linter, a security scan, or a real user on a screen reader finds the thing it was never asked to handle.

That’s the actual gap between a beginner’s use case and a developer’s. A blog post that’s slightly off in tone is a two-minute fix. A data-fetching function that’s slightly off in its error handling is an incident with your name near it. The loop looks the same from a distance (prompt, review, adjust), but what “review” has to catch is nowhere close to equivalent: injection risks, auth that looks handled but isn’t, a query that’s fine in a demo and falls over under real traffic, accessibility that was never part of the request because the tool had no way of knowing it mattered.

^{Fig. 2 — Not every AI tool sits at the same distance from your codebase. A chat window only knows what you paste into it. An in-editor assistant sees the file you’re in. An agentic tool can read the whole repo, run the tests, and open the pull request itself — which changes what “writing a prompt” even means.}

This is where the tooling itself matters more than a general guide has any reason to mention. A plain chat interface works fine for a one-off question, but everything has to be fed in and pulled back out by hand, and the model never actually sees your repository. In-editor assistants close part of that gap, seeing the file in front of you, usually one at a time. Agentic tools go further still — something like Claude Code can read across the codebase, run your test suite, coordinate changes across several files, and open a pull request for you to look at. That’s not a faster version of the same tool. It’s a different kind of collaborator, and it turns the prompt from a single message into something closer to a scoped handoff.

Reading Generated Code the Way You Would Read a Stranger’s

The useful mental model isn’t new. You already have it. When a pull request lands from someone you’ve never worked with, you don’t assume it’s correct because it runs. You ask what it’s actually doing, what it’s assuming about the data, and where it’s likely to break under conditions the author never considered. AI-generated code deserves exactly that posture, whether it came from a single chat prompt or a longer agentic session that ran while you were somewhere else.

^{Fig. 3 — The loop that holds up in practice: a prompt written with real context, a draft, automated tests, and a human review gate before anything reaches main. When review turns something up, the fix is usually to revise the prompt itself, not just patch the code, so the next draft doesn’t repeat the mistake}.

What matters is that review happens before the merge, not after something surfaces in production, and that automated tests are a first pass rather than a replacement for a person reading the code. Tests catch regressions. They don’t catch a solution that technically passes while solving the wrong problem, and they don’t catch a gap nobody thought to write a test for. The half of this loop that’s easy to skip is also the part that compounds: when review finds a problem, the fix that actually helps next time is updating what the prompt included, not just cleaning up the output by hand. For a general audience there usually isn’t a next prompt to improve. There’s just the next email.

A Discipline That Holds at Every Scale

Worth remembering: tools like Claude Code weren’t built only for the moments things go smoothly. The habits that make an AI assistant useful for a quick script are the same ones that keep you out of trouble on something that’s actually going to ship. Be specific about the constraints that matter, give it the context a stranger would need, treat the first response as a draft rather than an answer. A vague prompt produces the same generically plausible output whether you’re asking for a marketing email or an API endpoint. The general advice isn’t wrong about that. It just never has to deal with what happens when you skip it.

What differs is the judgment applied afterward. Someone using AI to draft an email is checking whether it sounds right. A developer reviewing AI-generated code is checking whether it holds up under load, survives an audit, and still makes sense to whoever opens the file next. Treating AI as a fast, occasionally overconfident collaborator rather than a threat or an oracle is probably the one habit from the casual world that genuinely holds up, once it’s scaled to match the stakes.

What Actually Carries Over and What You’ll Have to Add

Write prompts the way you’d write a ticket, with the framework, the existing patterns, and the constraints spelled out instead of assumed. Match the tool to the size of the job, and reach for something that can actually see your repo once a task crosses more than one file. Keep the review gate in place no matter how confident the output looks. Confidence in tone was never a reliable stand-in for correctness in logic. And when review turns something up, spend a minute updating the prompt or the shared context behind it, not just the code. That’s the step a general audience never needed, and the one that actually compounds.

The gap between a prompt that works and code that belongs hasn’t closed. It’s just moved earlier, into the way the request gets written in the first place, and it’s now more clearly yours to own.

This article draws on ideas and framing from AI for Anyone: The Beginner’s Guide to AI by Sebastian Huelswitt. If you want the gentler, fuller on-ramp — picking your first AI tool, writing a first prompt, and using AI for everyday tasks like emails and image generation — you can find the book here.

This Week in the News

🚀 TypeScript 7 Just Made Your Compiler 10x Faster: Microsoft’s Go rewrite of TypeScript is finally stable, and the numbers are wild. VS Code’s codebase compiles in 10.6 seconds instead of 125, Slack cut CI type-checking from 7.5 minutes to 1.25, and memory usage actually dropped. One catch worth knowing: there’s no programmatic API yet, so Vue, Svelte, and Astro projects are stuck on 6.0 until 7.1 lands. For everyone else, this is the easiest upgrade decision of the year.

🦀 Bun Rewrote Its Entire Codebase in Rust Using 64 Claudes in 11 Days: Jarred Sumner ported all 535,000 lines of Bun from Zig to Rust in 11 days using around 64 parallel Claude agents, with adversarial reviewer agents checking every line. The payoff: 128 bugs fixed, 20% smaller binaries, and the full test suite passing with nothing skipped. Bun is Anthropic-owned now, so grain of salt, but the workflow breakdown is genuinely worth reading.

⚡ Vite+ Goes Beta: VoidZero’s unified toolchain hit beta, bundling Vite, Vitest, Rolldown, Oxlint, and friends behind a single vp command that handles dev, test, lint, build, and monorepo task-running. With 1,300+ public repos already depending on it, “unified toolchain” is starting to look less like a pitch and more like a fact. If your package.json scripts section reads like a ransom note, this is your intervention.

🗺️ react-google-maps: Google Maps, But Make It React: The vis.gl team maintains this library of React components and hooks that wrap the Google Maps JavaScript API, letting you treat a map as a fully controlled reactive component. It also plays nicely with deck.gl for WebGL visualizations on top. Blessed are the maintainers who save us from wrapping imperative APIs in useEffect ourselves.

🎨 env.style: Never Ship to Prod by Accident Again: Ryan George whipped up a project called env.style to change your project’s favicon color based on what environment it’s in, so your dev, staging, and production tabs are visually distinct at a glance. Honestly useful. But if you need this, it’s probably also time to close a few tabs.

🛡️ OSV.dev: Google’s Open Source Vulnerability Database: Google built a distributed, open database of vulnerabilities in open-source software, with precise version-level affected ranges and an API you can query straight from your dependency tooling. Genuinely great infrastructure for the whole ecosystem. I hope whoever built this impressed the committee and got their promotion before the project gets sent to the Google graveyard.

🧭 Safari Ships an MCP Server: Safari Technology Preview 247 includes an MCP server that lets any compatible coding agent drive a real Safari window: reading the DOM, watching network requests, taking screenshots, and checking console output to debug your site autonomously. Apple showing up to the agentic party with a local-first, no-network-calls design is a pleasant surprise. Your “works in Chrome” excuses just lost their last line of defense.

Beyond the Headlines

🧙 Working With AI: A Concrete Example: Carson Gross (of htmx fame) walks through a real hyperscript parser bug where Claude nailed the root-cause investigation and tests but kept proposing hacky fixes until a human who knew the codebase stepped in. The most honest write-up of AI-assisted maintenance I’ve read in a while: be the sorcerer, not the apprentice.

🔁 Harness Engineering for Self-Improvement: Lilian Weng surveys the research on harnesses, the orchestration layer around models that manages workflows, memory, subagents, and self-improvement loops, from context engineering through evolutionary search over harness code itself. Dense, rigorous, and exactly the kind of post you bookmark and actually finish. Clear your calendar for this one.

🏗️ Apps After Agents: Kyle Mathews argues “software is dead” is wrong on both supply and demand: agents can’t absorb judgment-heavy “camera mode” work, and users prefer designed interfaces over formulating prompts. The real moat, he says, is your “substrate” of accumulated decisions and conventions. A genuinely useful frame for anyone tired of both the doomers and the maximalists.

💻 Learning to Code Is Still Worthwhile: Val Town founder Steve Krouse pushes back on the “nobody says learn to code anymore” narrative, arguing coding is worth learning the way math or literature is: for the meta-skills, the creative expression, and the joy. Short, sincere, and a nice palate cleanser after all the AI discourse above.

🎤24 Tips for Giving S-Tier Demos: PostHog’s Jina Yoon watched 50+ hackathon demos back to back and distilled what separated the great from the forgettable: one main point, get to it fast, demo against the painful alternative, and never apologize before you start. Required reading before your next sprint review. Tip 12 alone is worth the click.

Developer Toolbox

🌱 Wordgard: A schema-based, semantic rich-text editor library for the browser from Marijn Haverbeke, where you define exactly what content your documents allow instead of wrestling free-form HTML. Accessible, RTL-aware, collaborative-editing ready, and MIT licensed. The footer proudly declares “Contains 0% AI”, which in 2026 is practically a feature flag.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

AI can write your code in seconds. But should it?

We just launched Build with AI, and our new series, The Agentic Engineering Playbook, is already asking the hard questions.

Two parts are live already:

• Why vibe coding feels magical for prototypes, but breaks down at scale

• The four eras of agentic engineering, and where most teams actually stand today

Three more parts are coming, unpacking how to turn AI from a fast code generator into a real engineering multiplier.

Subscribe today to follow the complete series as new parts are released and claim your free welcome eBook.

Subscribe and Claim Your Free eBook

For years, the relationship between design and development followed a predictable rhythm. Designers explored ideas, tested them in static mockups, and eventually handed off a set of screens, specs, and good intentions. Developers took it from there, filling in the gaps that design never quite covers: edge cases, data structures, error states, the messy reality of production systems. It worked, mostly, because everyone understood their role in the relay.

That rhythm is breaking down, and it’s worth understanding why, because the shift changes what actually lands on your desk before you write a line of code.

Before we get to that, here’s a look at what’s making news this week:

• Claude Sonnet 5 is here, though lifted export controls on Fable 5 are stealing its thunder

• GitHub now lets you restrict issue creation (link from GitHub blurb) to collaborators with write access

• Vercel Functions now support Docker, so you can deploy containers directly

• How TypeScript 7’s Go-based compiler made VS Code over 10x faster to build

• Oxlint, a Rust-based linter that turns 30-second ESLint runs into sub-second ones

Prototypes That Behave Like Real Products

A new generation of AI-assisted tools, including Lovable, v0.dev, Bolt.new, Figma Make, and Replit, lets designers build interactive prototypes that don’t just look like an app but function like one. Screens respond to input, flows execute end to end, and users can complete real tasks inside something that was assembled from a natural language description rather than a stack of tickets. What used to take a sprint or two of coordinated effort between design, product, and engineering can now happen in an afternoon, in the hands of a single person who understands the problem well enough to describe it clearly.

^{Fig. 1: I want to build the app described in the attachment” — a plain-language prompt turns a one-page brief into a working homepage, complete with a nav, hero section, and live stats.}

This is not a gimmick. Designers are using these tools to validate ideas with real users before a single developer gets involved, testing whether a value proposition resonates and whether a flow makes sense long before anyone commits to an architecture. That’s a genuinely good thing. Cheaper validation means fewer wasted sprints building something nobody wanted, and it means the thing that eventually reaches you has already survived contact with actual users.

The complication is what happens next. In some organizations, that validated prototype isn’t just inspiration for a spec anymore. It’s the artifact itself, checked into a repository and treated as a starting point for the real build. Some designers are going further still, using tools like Claude Code directly inside an editor to scaffold application structure, generate front-end and back-end code, and wire up basic services, all before a developer is looped in at all.

The Gap Between “It Works” and “It’s Ready”

If you’re a developer, you’ve probably already brushed up against this without naming it. Maybe a product manager forwarded you a Lovable prototype and asked how long it would take to “make it real.” Maybe a designer handed you a working demo built with v0 and seemed genuinely confused when you explained that “working” and “production-ready” are not the same claim.

They’re not being naive. The prototype really does work, in the sense that matters to a designer validating an idea: it demonstrates behavior, and it lets users complete tasks. But there’s a meaningful gap between a prototype that demonstrates an idea and a system that can hold up in production, and closing that gap is still, unmistakably engineering work.

^{Fig. 2: Listings, pricing, and booking flows, fully styled and clickable. Convincing enough to hand to a real user for testing, though nothing behind these screens has been built yet.}

A few things tend to be true of AI-scaffolded prototypes, regardless of which tool generated them. Authentication is often stubbed out or handled in a way that would never survive a security review. Data validation is inconsistent because the AI is optimized for showing behavior rather than defending against malformed input. Error handling covers the happy path and little else.

Accessibility is frequently an afterthought, since the tools were optimized to produce something visually convincing and functionally demonstrable, not something that passes a screen reader test. And the underlying architecture, however clean it looks, was generated to satisfy a prompt, not to scale, so assumptions about data models or service boundaries may not hold once real usage patterns show up.

None of this means the prototype is worthless. It means your job now includes a step that used to be implicit: figuring out exactly what you actually inherited before you start building on top of it.

Treat It Like a Pull Request From Someone You’ve Never Met

The most useful mental model here is one you already have. When you review a pull request from a junior developer, you don’t assume the code is correct just because it runs. You ask what it’s actually doing, what assumptions it’s making, and where it’s likely to break under conditions the author didn’t consider. AI-generated scaffolding deserves exactly that same posture, whether it arrived as a Lovable export, a v0 component, or a Claude Code session someone ran before you were in the room.

That means asking pointed questions early, ideally before you commit to building on top of what you were handed. What’s actually persisted versus what’s mocked in the local state? What happens when a request fails, or when a user submits something malformed? What was tested with real users, and what was simply assumed to work because it was demonstrated correctly in a single session? Is there an authentication layer here, or does it just look like one? These aren’t gotcha questions aimed at the designer who built the prototype. They’re the same questions you’d ask of any unfamiliar codebase, and asking them early saves you from discovering the answers the hard way three sprints later.

It also helps to have this conversation with designers directly, rather than assuming they know where the line sits. Most designers using these tools are not trying to skip engineering. They’re solving a real problem: getting to validated learning faster, with fewer people and less overhead. They generally want to know where their prototype’s assumptions will cause you trouble, because a designer who understands that gap can scope their next round of prototyping more usefully, and can stop treating “it works in the demo” as equivalent to “it’s ready to ship.”

The Engineering Value Is Shifting, Not Shrinking

There’s a temptation to read all of this as a threat, as though AI-assisted prototyping is quietly encroaching on territory that used to belong to developers. That framing misses what’s actually happening. The work that’s disappearing is the work of translating vague requirements into a first functional version, the scaffolding and boilerplate that ate weeks of calendar time without much intellectual weight to it. What’s left, and arguably what was always the hard part, is exactly the stuff AI tools are bad at: reasoning about scale, securing a system against real-world abuse, designing data models that won’t need to be rebuilt in six months, making something usable for people with disabilities, and maintaining a codebase over years rather than a demo over an afternoon.

That’s not a smaller job. It’s a more concentrated one. The parts of development that require judgment, not just output, are becoming a larger share of what you actually spend your time on, because the parts that didn’t require judgment are increasingly handled before you arrive.

This also changes what’s worth getting sharper at. Being able to read an unfamiliar, AI-generated codebase quickly and spot where it’s fragile is now a core skill, not a nice-to-have. So is being explicit and precise when you push back on scope or timeline, because “the prototype already works” is going to be a recurring argument you’ll need to answer with specifics rather than vague discomfort. Security and accessibility reviews stop being a checklist you run near the end of a project and start being something you do as a first pass on anything that arrives from a design tool, since those are exactly the areas most likely to have been skipped.

The Same Tools Are Yours to Use, Too

It’s worth remembering that Claude Code, and tools like it weren’t built exclusively for designers making the leap into software. They’re development tools first, and the same techniques designers are using to scaffold a prototype quickly are just as available to you when you’re standing up a new service, exploring an unfamiliar API, or getting a rough version of a feature in front of a stakeholder before committing to a final approach.

The habits that make these tools useful are the same ones described in every good code review or design brief: be specific about what you want, provide the context that actually matters, and treat the first response as a starting point rather than a finished answer. Vague prompts produce the same vague, generic output whether you’re a designer exploring a persona or a developer scaffolding an endpoint. The developers getting the most out of AI coding assistants tend to work the same way experienced designers do: iteratively, asking the tool to explain its reasoning, comparing alternatives, and pushing back when something feels underspecified rather than accepting the first plausible-looking result.

This matters because the line between “AI helped a designer build something” and “AI helped a developer build something” is thinner than it looks. The tools are converging. What still differs is the judgment applied to the output. A designer evaluating an AI-generated flow is asking whether it serves the user. A developer evaluating AI-generated code is asking whether it will hold up under load, survive an audit, and still make sense to the next person who opens the file. Treating AI as a fast, occasionally overconfident collaborator, rather than either a threat or an oracle, is probably the single most transferable skill in all of this.

A Few Things Worth Carrying Forward

The shift toward AI-assisted prototyping isn’t going to reverse, and treating it as a fad to wait out is the wrong instinct. A more useful posture is to get specific about where the value of your engineering judgment actually sits, and to make that value visible earlier in the process rather than discovering it under deadline pressure.

A few concrete habits are worth building now. Ask what’s real and what’s demonstration-grade the moment a prototype lands on your desk, before you start estimating work against it. Run a quick security and accessibility pass on any AI-generated scaffold as a default step, not an optional one, since those are the areas most consistently under-covered. Talk to whoever built the prototype about what they validated with users and what they simply assumed, because that conversation will tell you more about risk than reading the code alone. And resist the urge to either dismiss these tools as toys or treat their output as trustworthy by default. Both instincts will cost you time.

The gap between an idea that works and a system that lasts hasn’t closed. It’s just moved earlier in the process, and it’s now more clearly yours to own.

This Week in the News

🧠 Claude Sonnet 5 arrives to a distracted crowd
Anthropic shipped Claude Sonnet 5, its latest mid-tier workhorse. Solid release, unfortunate timing: with export controls on Fable 5 now lifted, most devs are eyeing the bigger sibling instead.

🔒 GitHub lets you lock down issue creation
GitHub’s latest move to keep project management sane in the agentic era: you can now restrict issue creation to collaborators with write access. Fewer drive-by tickets, cleaner backlogs.

🎨 Meta open-sources Astryx, a design system built for agents
Meta released Astryx, an open-source design system built to play nicely with AI agents. It is reportedly battle-tested across 13,000 internal apps, so it arrives with more mileage than most v1 releases.

🐳 Vercel Functions now speak Docker
Bring your Dockerfile to Vercel Functions and deploy containers directly. A genuinely useful addition, even if longtime users will note it took only 6.5 years to reinvent ZEIT.

Beyond the Headlines

⚡ How TypeScript 7 made VS Code faster to build
The VS Code team adopted TypeScript 7, the Go-based compiler rewrite that is over 10x faster in many cases. They started migrating while TS 7 was still under construction, and both teams came out ahead: faster builds for VS Code, a better-tested release for TypeScript.

💾 Meta’s AI storage blueprint at scale
If AI is the brain, storage is the memory. Meta’s infra team breaks down how they keep exabytes of training data fast and reliable as frontier model releases shrink from months apart to weeks.

🌗 Dark mode with web standards
Ollie Williams shows how to build a proper dark mode toggle with a meta tag, the color-scheme property, and barely any JavaScript. Includes the gotchas, like why prefers-color-scheme ignores your in-page toggle.

📺 The business of TanStack
CodeTV’s Build Log follows Tanner Linsley, who built TanStack into a thriving open source community and now faces the harder problem: turning it into a sustainable business.

Developer Toolbox

🦀Oxlint: A Rust-based linter for JS/TS from VoidZero (Evan You’s tooling company) that turns 30-second ESLint runs into sub-second ones. As of March, its plugin system runs most existing ESLint plugins as-is, so the “but my custom rules” objection is mostly gone. No migration needed either: npm install -D oxlint, let it handle the fast first pass, and keep ESLint for the gaps. Preact, PostHog, and Midjourney already run it.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Social engineering is about manipulating people's emotions. Identify the susceptibilities that hackers use to exploit people.

This NINJIO Insights Report dives into the key emotional susceptibilities that make social engineering work and offers concrete steps that your security team can take to equip your workforce to resist cyberattacks.

Download the Guide

Microservices promise modularity. You decompose a system into small, focused services, each owning its domain, each deployable independently. It sounds clean. Then you look at the network diagram and realize that every service has a public address, every team is implementing JWT validation in their own way, and refactoring a single service boundary requires coordinating changes across four different client teams.

That is not a distributed system. That is a distributed mess with extra steps.

The edge server pattern exists to fix this at the architectural level. The idea is straightforward: all external traffic enters your system through one controlled point. Everything behind it is private. One door in, many rooms inside. This article goes deep on what that actually means in practice, why the benefits compound as your system grows, and what you are genuinely giving up in exchange.

The Problem with Open Borders

Imagine a typical early-stage microservices setup. The product team exposes port 8081. The review service is on 8082. The recommendation engine lives at 8083. Your frontend knows these addresses. Your mobile app knows them. A few third-party partners have been given direct integration URLs. Everyone is talking to everyone, and it works well enough to ship.

Now the problems start accumulating, and they are not obvious until they hurt.

^{Fig. 1: Open borders vs. a single edge. On the left, every service is reachable and must handle auth independently. On the right, the edge is the only entry point.}

Security becomes a distributed responsibility

When every service is externally reachable, every service has to handle authentication. In practice this means each team implements their own token validation logic, maintains their own secret rotation process, and writes their own integration tests for auth edge cases. The surface area for misconfiguration grows linearly with the number of services.

A single service that skips a validation check, misconfigures a CORS header, or accidentally exposes a debug endpoint becomes a gap in the entire system. You cannot audit security policy in one place because there is no one place. You have to review every service independently and trust that every team got it right every time.

Internal structure leaks into external contracts

Suppose the product service has grown large enough that the team wants to split it: one service handles product metadata, another handles inventory. Internally this is a clean refactoring. Externally it is a breaking change for every client that has been hitting /product-service/ directly.

You now have three options, none of them good: freeze the refactoring until you can coordinate a client migration, run the old service indefinitely as a shim, or accept that you will break integrations. The real problem is not the refactoring; it is that you let internal structure leak into external contracts in the first place. Direct service access makes that inevitable.

Network security becomes exponentially harder

Every externally reachable service needs its own firewall rules, its own TLS certificate, its own rate limiting configuration. For five services this is manageable. For twenty it is a full-time job. For fifty it is a source of chronic incidents. Services that have no business accepting external traffic, internal caches, configuration stores, event buses, still need to be deliberately locked down rather than simply unexposed.

“The fundamental issue is not any single vulnerability or misconfiguration. It is that an open-border architecture makes deliberate exposure the exception and accidental exposure the default. The edge server inverts that.”

What an Edge Server Actually Does

At its core, an edge server is a reverse proxy. External requests arrive, the edge inspects them and routes them to the right internal service. Clients never know the internal topology. But a reverse proxy is just the foundation. A well-implemented edge server is doing several distinct jobs simultaneously.

Path-based routing

The most fundamental capability is routing requests based on their URL path. A request to /product-composite/** goes to the product composite service. A request to /eureka/** goes to the discovery server. These rules live in configuration, not in client code, which means they can change without clients noticing.

This is more powerful than it first appears. Your internal service might live at an address that makes sense to your infrastructure team but would be meaningless or confusing to external consumers. The edge lets you present a URL structure that reflects your API design, not your deployment topology. The two do not have to match.

Notice lb://product-composite. The lb:// scheme tells the gateway to resolve the service via the load balancer, which in a Spring Cloud setup means using service discovery. The edge does not need to know the IP address of the product composite service; it just asks the registry for a healthy instance and routes there. This means your edge routing config stays stable even as services scale up, move, or restart.

Service hiding

Not every service should be reachable from outside. Your order processing service, your internal event bus adapter, your ML feature store: these components exist to serve other services, not external consumers. In an open-border setup you have to actively lock them down. With an edge server, they simply have no externally routable address. They exist behind the edge and are unreachable by definition.

Centralized authentication and authorization

Rather than implementing JWT validation in every service, you implement it once at the edge. The edge verifies the token signature, checks expiry, and rejects unauthorized requests before they ever reach your internal network. Internal services can then trust that any request they receive has already been authenticated.

This is sometimes taken further with header propagation: the edge extracts claims from the token and forwards them as headers (X-User-Id, X-User-Roles) so internal services have user context without re-parsing the token themselves. Each service still makes its own authorization decisions based on those headers, but the cryptographic verification happens exactly once.

Centralizing authentication at the edge does not mean internal services should blindly trust everything they receive. Defense in depth still applies. But it does mean you have one authoritative place where external identity claims are verified.

HTTPS termination and protocol handling

External clients always communicate over HTTPS with the edge. What happens internally is an implementation detail. The edge terminates TLS, handles certificate renewal, and communicates with internal services over HTTP on a private network. This means internal services do not each need their own certificates, do not each need TLS configuration, and do not each introduce latency from TLS handshakes on every inter-service call.

Graceful failure handling

When an upstream service is unavailable, the alternative to a well-configured edge is that the raw error propagates directly to the client: a 500 with an internal stack trace, a connection timeout with no explanation, a response body that includes your service class names and database schema details.

The edge is the right place to intercept upstream failures and decide what the external representation should look like. A cached response for read-heavy endpoints that can tolerate slight staleness. A structured error response that tells the client what went wrong without revealing internal state. A degraded response that returns partial data when one upstream is down but others are healthy.

Routing Rules as Design Decisions

One thing that becomes apparent quickly when you start working with an edge server: the routing configuration is not just plumbing. Every decision you make about URL structure, versioning, and predicate logic is a decision about how you want the outside world to think about your system.

URL structure as API design

The path you expose externally does not have to match your internal service name. You can expose /api/v1/products while internally routing to a service called product-composite-v3. You can version your public API independently of your internal deployment cadence. You can reorganize your internal services without changing a single external URL, as long as you update the routing rules.

This separation matters most when you are managing third-party integrations. External consumers build against your URLs. If those URLs map directly to internal service names, every internal refactoring becomes a negotiation with your consumers. If they map to stable, intentionally designed API paths, you keep full control over your internal evolution.

Predicate-based routing beyond paths

Path matching is the baseline. Route predicates let you go further. You can route based on the hostname in the request, which is useful for supporting multiple environments through a single edge deployment with different backend targets. You can route based on request headers, which is the foundation for several useful patterns:

• Canary deployments: route requests with a specific header (X-Beta-User: true) to a new version of a service, while all other traffic goes to the stable version.

• A/B testing: route a percentage of traffic based on a user segment header, without any changes to the services themselves.

• Client-specific routing: route mobile clients (detected via User-Agent) to a backend optimized for mobile response shapes, while web clients hit a different implementation.

The routing layer is where you manage change without breaking things. A feature flag, a traffic split, a version migration: all of these can be implemented at the edge without touching a single service deployment.

Selective Exposure: The Discovery Server Example

One decision that reveals the real nature of the edge server is what to do with internal infrastructure. Take the service discovery server (Eureka, Consul, or similar). It is primarily an internal component: services register with it, other services query it to find healthy instances. There is no reason for external clients to interact with it directly.

But operators have a legitimate need to observe its state. When something is misbehaving, you want to know: which instances are registered? Which are reporting as healthy? Which went missing in the last five minutes? Completely blocking external access to the discovery server means operators cannot check this without SSH access to the internal network.

^{Fig. 2: Only the read-only /eureka/** endpoints are exposed through the edge. Registration, deletion, and internal query endpoints stay private.}

The solution is selective exposure. Route a read-only subset of the discovery server API through the edge under a controlled path:

Operators can now hit /eureka/apps to see registered services, or pull up the Eureka web UI at /eureka/ for a visual status overview. The broader discovery infrastructure (registration endpoints, internal service-to-service queries) stays private. You expose exactly the surface that serves a legitimate external use case, and nothing more.

This is the right mental model for the edge server across every service in your system. The question is never just ‘should this be external or internal?’ The question is ‘which specific surface of this service needs to be external, and to whom?’ The edge gives you the precision to answer that per endpoint rather than per service.

Tradeoffs and Practical Considerations

Availability

Edge servers are stateless, so the single-point-of-failure concern is manageable: run two or three instances behind a load balancer and failover is fast. The risk is real but the mitigation is straightforward.

Performance overhead

The extra hop is typically single-digit milliseconds and rarely the bottleneck. The bigger concern is thread management under high throughput. Reactive implementations like Spring Cloud Gateway (Project Reactor) handle this well since they never block a thread waiting on an upstream response.

Local development friction

The most underestimated tradeoff. With an edge in the mix, services need to be registry-discoverable, which complicates local runs. Solve it with a full Docker Compose stack, a dev-mode bypass config, or by stubbing the edge in tests. Painful only if you leave it unplanned.

Edge server vs. API gateway

Same architectural pattern, different feature depth. A lightweight edge server (Spring Cloud Gateway, Nginx, Traefik) covers routing, auth, and protocol management, which is enough for most internal systems. A full gateway product (Kong, Apigee, AWS API Gateway) adds per-consumer rate limiting, developer portals, and billing integration. Worth it only if the API itself is a product.

Key Takeaways

This Week in the News

⚡ Cloudflare Workers Now Live in 60 Seconds, No Account Needed: Run wrangler deploy --temporary and get a live Worker instantly. It stays up for 60 minutes, and you can claim it to make it permanent. Exactly the kind of friction removal that makes agents and fast-moving developers happy.

🗂️ Polygraph Gives AI Agents a Map of Your Entire Codebase: Built by the Nx team, Polygraph indexes every repo you have access to and maps how they connect through packages and APIs, effectively turning scattered codebases into a synthetic monorepo. It’s a meta-harness for agents, not an agent itself, and it comes with cross-session memory. Free during early access.

📖 MDN Now Has an Official MCP Server for Your Coding Agent: MDN’s new MCP server pipes its documentation and browser compatibility data directly into your editor or IDE. Your LLM gets accurate, current web platform info instead of pulling from stale training data when writing HTML, CSS, or JavaScript. A quiet but meaningful upgrade for AI-assisted web development.

🤖 Vercel’s Eve Is an Open-Source Framework for Building Serious Agents: Eve brings durable execution, sandboxed compute, human-in-the-loop approvals, and evals to agent development. An agent is just a directory where each file describes one component, making the structure easy to read at a glance. Vercel-native by default, but fully portable with your own keys.

🚧 React Compiler’s Rust Integration Gets Pulled Over Binary Size Bloat: Integrating the React Compiler natively into Oxc was the right performance call, but the binary size ballooned enough to affect all Rolldown and Vite users. The integration has been temporarily pulled while the team works on slimming it down. Doing the right thing the hard way.

Beyond the Headlines

⚔️ The Framework Wars Are Happening Again, This Time for AI Agents: React beat batteries-included contenders by doing one thing well, and Next.js grew on top to supply the rest. The same pattern is playing out in AI agents: narrow agents will win, and a meta-harness layer will grow above them. A sharp read from the Nx team on where the agent ecosystem is headed.

🔁 The Harness Loop: Where Autonomous Agents Work and Where They Don’t: A harness-level loop sits outside the agent loop. Work goes into a queue, a machine picks it up, attempts it, and the harness decides whether to continue, inject another message, or start fresh with modified context. Great for porting code, performance explorations, and security scanning, but tends to produce overly defensive code when left entirely hands-off. A thoughtful, honest take from Armin Ronacher.

🌿 Git Worktrees: The 2015 Feature That AI Agents Just Made Relevant: Git worktrees let you check out multiple branches simultaneously without stashing or switching context. They have been around for a decade but are suddenly essential now that AI coding agents need to work across branches in parallel. A solid explainer if you have never reached for this feature before.

🧱 JavaScript Still Can’t Install a Full-Stack Module: Rails and Laravel let you install a package that ships a full vertical slice: backend, frontend, and database model, all wired up and ready to go. JavaScript still can’t do this. It matters for AI agents too, since models work better with pre-built, well-tested modules that hide complexity behind a thin interface rather than hand-rolling everything from scratch. A well-argued case from the Wasp team on a gap the JS ecosystem hasn’t closed.

📊 WebAssembly Runtimes Benchmarked in 2026: Less Hype, More Numbers: A benchmarking follow-up tracking whether WebAssembly runtimes have actually gotten faster year over year. Wasmer comes out as the best overall performer, with WAVM, WAMR, and Wasmtime close behind. The new wide_arithmetic instructions are proving to be a significant boost for crypto code on runtimes that support them. Exactly the kind of update the Wasm ecosystem needs.

Developer Toolbox

🥷 Kage: Clone Any Website Into a Static, Offline Mirror: Kage (影, "shadow") renders pages through headless Chrome, captures the fully assembled DOM, then strips out every script, event handler, and network call. CSS, images, and fonts are downloaded and rewritten to local paths so the offline copy looks identical to the live site. One command to clone, one to serve. A pure-Go binary with no dependencies and no fuss.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the expert

Aristeidis Bampakos wrote this issue’s featured article on building smart Angular apps with Firebase AI Logic. He’s a Google Developer Expert (GDE) for Angular with 20+ years in software development. Based in Athens, he leads web development at Plex Earth, specializing in Angular. An award-winning author of Learning Angular and Angular Projects, he’s passionate about growing the developer community through writing, speaking, and teaching.

In this article, we will learn how to build smart and scalable Angular applications using the Firebase services from Google. We will see how to extend Angular applications by adding agentic AI capabilities using the Firebase AI Logic SDK.

The article is greatly inspired by my new book, Angular Projects – 4th edition, which you can also purchase by scanning the QR code below:

^{Figure 1: Book QR code}

Every chapter of the book is a separate real-world Angular project with modern technologies. Each project reflects how real teams work: forms, routing, data, and the small choices that make an application feel finished.

In one of the chapters, you will build CityPass Parking, an AI-enabled parking validator that allows users to submit car tickets and verify the time of their stay in the parking. The main feature of the project is a form to enter ticket details:

^{Figure 2: Ticket form}

The form consists of a date picker component and two input boxes that allow users to enter the required data.

Business Logic in Angular

The business logic layer in an Angular application defines how things are done in the application, and it is typically used for data access and complex tasks, such as:

• Accessing data from a REST API over HTTP

• Interacting with the local storage of the browser

• Performing data transformations and calculations

Developers use Angular services to implement the business logic in an Angular application and make it available to components using the Angular Dependency Injection (DI) mechanism.

A popular best practice in the Angular community is that services should do one thing and do it well. The practice is based on the Single Responsibility Pattern (SRP), and it is described in the official Angular styleguide here. In the CityPass Parking application, we have a single service that creates a new parking ticket:

When the business logic layer needs to support more use cases that cross domain boundaries, you must create a new service. We will see an example of this scenario in the following section.

Adding new features

The form of creating new tickets in the CityPass Parking application requires users to enter the location of the parking manually. According to the requirements, we could improve it further by allowing users to select the location from a list. The development team should make the following changes in the application:

• Change the UI of the specific component and add a select component for the available locations.

• Create a new service to retrieve the locations and populate the select component:

The preceding steps require time and resources from the development team to implement the new feature. We could leverage the power of AI and support the new feature and future changes without ever touching the UI, using prompts.

We have already mentioned that Angular services should follow the one concept per file rule. One exception to this rule is when AI comes into the game because it can understand what it can do and when, with the right prompt. In the following section, we will see how AI can orchestrate the business logic of an Angular application and use prompts with Firebase AI Logic.

Introducing Firebase AI Logic

The Firebase AI Logic is a service of the Firebase product family that enables developers to add agentic AI capabilities in client-side applications:

• It supports a variety of programming languages, including JavaScript, which makes it appealing to Angular development.

• It supports Gemini models and allows developers to interact with the Gemini products securely. Firebase AI Logic is connected with a Firebase project internally, so that no Gemini API key is required on the client side of the application.

• It is the recommended approach when your existing infrastructure is based on Firebase because it integrates seamlessly with other Firebase services.

In the following image, you can see a high-level overview of an AI agent based on the Firebase AI Logic, inside an Angular application:

^{Figure 3: Firebase AI Logic}

The yellow box resides on the server side, in Firebase services, and defines the Gemini model that the agent interacts with.

The blue boxes are the Angular application and the AI agent that reside on the client side. The Angular application uses the Firebase AI SDK, which is an npm package that exposes all the required methods for interacting with Firebase AI Logic, to create an agent. The LLM instructions describe the persona of the agent, and the tools define what the agent can do in the Angular application.

Agent tools

In the context of agentic AI, a tool is also known as function calling because it can call existing functions in an application. In the context of Angular, the agent communicates with the existing business logic layer to expose predefined methods as tools:

^{Figure 4: Agent tools}

As we see in the previous image, the AI agent of the CityPass Parking application exposes two tools: one for creating tickets and another for retrieving parking locations. The agent is also an Angular service that communicates with the Tickets and the Locations service classes to access their public API:

^{Figure 5: Business logic layer}

The tools of the agent are defined in the functionDeclarations property of a FunctionDeclarationsTool object:

In the above snippet, we define only one tool for creating parking tickets. A tool has the following properties:

• name: The name of the tool. Agents respond with a suitable tool name according to the received prompt.

• description (optional): A short description.

• parameters: The properties needed by the agent to call the particular tool. Firebase AI Logic uses the Zod library to define a typed schema for the call parameters.

The persona of the agent is a simple variable, such as the following:

According to the previous snippet, the agent can convert dates to ISO strings and placemarks and addresses to coordinates.

We use the getGenerativeModel method from the firebase/ai package to combine the previous information with a Gemini model of our choice:

In the preceding snippet, the ai parameter comes from the configuration of a Firebase application that we have associated with the Firebase AI Logic through the Firebase Console.

The generated model can start listening for prompts using the following snippet:

The startChat method initiates a chat session between the agent and any caller. The application forwards prompts to the Gemini model using the snippet below:

When the model returns a response, we can extract the selected tool and call the appropriate method from the service:

The preceding snippet shows the execution of the tool for creating new parking tickets. The development team can now use the same agent to create a new tool for the retrieval of the available parking locations and expose it to the rest of the application. They will not need to modify the UI because users will be able to describe the new requirements with a prompt.

Security considerations

The Firebase AI Logic is a secure solution for adding agentic capabilities in a client-side application, as all interactions with the AI model go through Firebase services. Additionally, we can enhance the existing security measures with Firebase Server Templates. Firebase Server Templates move part of the agent to the server side, along with the Gemini models, and define them in a template:

^{Figure 6: Firebase Server Templates}

As shown in the previous image, the persona and the tool definition have been moved to the Firebase services. The described method has the following advantages:

• Prevents prompt injection.

• Faster development iteration. Any change in the tool or the agent requires modifying the template.

• Instant addition of new features. The server maintains multiple templates, and the application can switch to them using an ID.

Firebase Server templates are a new feature in the Firebase AI Logic service that ensures security is at the forefront of any AI interaction.

Conclusions

The Firebase AI Logic is a secure and quick way to add agentic AI capabilities to an Angular application. The versatility of Firebase Server Templates makes it even more secure as it moves critical parts of the AI agent to the server. However, keep in mind that not everything in an application should be a prompt. Make a prompt for:

• Common tasks: Everyday tasks that your users do.

• Easy tasks: Small tasks that need a small amount of information.

• New features: Introduce AI gradually in your application.

If you have the previous best practices in mind while designing AI experiences, you will build applications that your users will love to use!

This Week in the News

🤖 Flue 1.0 Beta: Cloudflare’s Answer to the Agent Framework Wars: Not to be outdone by Vercel, Fred K. Schott and the Cloudflare crew dropped a beta for Flue, an open TypeScript-first agent framework with a hard stance against vendor lock-in. The headline addition is a clean split between autonomous Agents for open-ended tasks and deterministic Workflows for when you want exact control. Channels let you drop agents directly into Slack, GitHub, Linear, and more, and a durable event log means a crashed process picks right back up where it left off.

🔷 TypeScript 7.0 RC is Here, and It’s Written in Go: The TypeScript team has ported the entire codebase from TypeScript over to Go, and with native code speed and shared memory parallelism, TypeScript 7.0 is often about 10 times faster than TypeScript 6.0. The RC is available now via npm install -D typescript@rc. The catch: this version locks in 6.0’s stricter defaults as hard errors, so strict is on by default, target: es5 is gone, and moduleResolution: node is out the door. Worth reading the migration notes before you upgrade anything in prod.

🧪 SvelteKit 3.0, Vue 3.6, Vite 8.1, and Astro 7.0 are all in beta
A busy pre-release season for the JS ecosystem, four major framework updates are racing toward stable at once. If you’ve been waiting to see where the frontend tooling landscape lands before committing to a stack decision, now’s a good time to start poking at the betas.

⚙️ WASI 0.3 is officially here and async is now native to WebAssembly
The WASI Subgroup voted to ratify WASI 0.3.0, rebasing WASI onto the WebAssembly Component Model’s async primitives. The big win: the host is now the one in charge of managing the one event loop shared by all components, which means components can finally be composed with each other without their event loops stepping on each other’s toes. For most microservices, this will reduce the time for calling other microservices from milliseconds to nanoseconds.

🧠 2-Day Claude AI Mastery Workshop: Live This Weekend

Claude has been shipping fast: Skills, Connectors, Cowork, vibe coding, and most people are still catching up. This weekend’s live workshop condenses 800+ hours of research and real-world practice into 16 focused hours covering Claude’s three modes, automation with Skills and Connectors, and 10+ AI tools and workflows. Saturday & Sunday, 10 AM – 7 PM EST. Register here.

Beyond the Headlines

💸 Never Waste a Token
Sunil Pai digs into a problem that’s easy to miss until it shows up in your billing dashboard: when your process dies mid-inference, you don’t just lose your place, you lose money. The fix is a durable buffer sitting between your agent and the LLM provider, so a mid-stream deploy or crash doesn’t force a full retry. Resumable streaming and crash recovery turn out to be one mechanism, the same durable chunk log; the only question is whether a live producer is still attached.

🌐 How Building an HTML-First Site Doubled Users Overnight
A real-world case study where ditching the React SPA in favour of server-rendered, progressively enhanced HTML wasn’t just a philosophical choice, it was the one that worked. When the site launched, the number of people completing the form doubled. The analytics team didn’t even know where these users were coming from, your JavaScript-based analytics package doesn’t see the users you’re bouncing because of JavaScript failures.

👁️ Smart Ignore Regions: Visual Testing That Learns Without Looking Away
The classic pain of visual regression testing: dynamic content like timestamps and footer copy triggers false positives on every build, so you draw a box around it and move on, except now you’ve created a blind spot. Vizzly’s smart ignore regions use Honeydiff’s change metadata to find recurring dynamic areas, ask you to confirm whether the change is expected, and use that decision on future reviews without turning the whole area into a blind spot. In their own dogfooding, confirming one footer region took 41 changed screenshots out of the review queue without changing the test suite.

🤖 Building a WASM-Powered Scanner Driver in the Browser
A fun one: a dev resurrected an old USB scanner with no modern driver support by running a WASM-powered emulator in the browser, bridged to the physical hardware via WebUSB. Niche, sure, but it’s a great illustration of how far browser APIs have come when you actually push them.

🎨 Orbit: Polar’s LLM-Safe Design System
The problem isn’t that LLMs can’t write CSS or Tailwind, they write it fluently. The problem is that they write it without being aware of the underlying decisions. Polar’s new Orbit system bets on making off-brand choices structurally impossible: if a value isn’t a design decision they’ve actually made, it should not pass CI. Intent-named tokens, typed props over raw class strings, and ESLint rules that enforce it all.

Developer Toolbox

🎲 PolyCSS
PolyCSS renders solid and textured 3D meshes in the DOM without WebGL — each polygon is a real element you can style, click, and inspect. It supports OBJ, glTF, GLB, and MagicaVoxel VOX files and works with vanilla JS, React, and Vue. Mostly a curiosity, but the kind that makes you want to open the builder just to see how far you can push it.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Microservices promised a clean world. Small, isolated services, each doing one thing, each deployable on its own. In theory, a developer can work on a single service, test it in isolation, and ship it without needing to understand the rest of the system. For teams burned by monolithic codebases that had grown into unmaintainable sprawl, the appeal was real.

But the promise comes with costs that compound as a system grows, and most architecture discussions gloss over them until a team is already deep in the weeds.

Before we dig deeper into this, here’s a TL;DR you’ll need:

• 🎨 Node-RED 5.0: the biggest editor overhaul in the project’s history

• 🖌️ A Jane Street designer now prototypes in Claude Code more than Figma

• 📝 How building an HTML-first site doubled a company’s users overnight

• 📅 Node.js is finally fixing its confusing release schedule

• 🪟 How Aave built a Liquid Glass component library for the web

• 👾 Can Chrome’s built-in AI play Zork? Not really

The Docker Build Loop Nobody Warned You About

Consider what happens when you begin with a straightforward to-do service and an auth service. Two services, manageable. But product requirements evolve, as they always do. You need email notifications when users are added to groups. You need rate limiting on registration to prevent email flooding. You need organizational structures with departments, permissions, and roles. Suddenly you have five services, each with its own database, each with dependencies on at least two others.

In theory, microservices are meant to be independent. In practice, real production systems rarely achieve this. Services end up needing data from each other constantly, and each new feature decision pulls at those dependencies further. The dream of true service isolation runs into the reality of shared business logic.

The first place this becomes painful is local development. When you are building a feature that touches the org service, the auth service, and the to-do service simultaneously, you are no longer working on one small service. You are building across three repos, running multiple Docker containers, waiting on separate builds, and debugging the network glue between them every time something breaks. For a small team moving fast, this overhead does not scale the way the architecture diagram suggested it would.

There is a real pattern here: teams start with microservices because the architecture looks clean on a whiteboard, then spend a disproportionate amount of their engineering time not building features, but managing the plumbing between services.

When Your Services Have No Idea What the Others Are Doing

There is a subtler problem that compounds the above, and it is harder to see until a system reaches a certain size. In a microservices architecture, no single service has full visibility into what is happening across the system. Each service operates in its own process, in its own memory space, talking to others only through network calls.

This creates a condition that is easy to underestimate: services end up duplicating checks on each other’s work because no service can fully trust what any other service has already done.

A classic example is auth verification. A developer working on the org service cannot know with certainty that the upstream to-do service has already verified the user’s role. So they add their own auth check. Then a project management service is built later, and it does the same. Eventually, a single user action triggers multiple redundant calls to the same auth service, a phenomenon that plays out at enormous scale in large systems.

DoorDash documented a version of this internally, where a single order placement triggered roughly 300 calls to the account service, precisely because all downstream services independently wanted to verify account state.

Beyond the redundant calls, there is the problem of circular dependencies. In a modular codebase, the compiler catches a circular dependency at build time and refuses to proceed. In a microservices architecture, those circular dependencies manifest at runtime as network calls, completely invisible at compile time. By the time you discover the problem, you may be debugging a cascading failure in production

What Nanoservices Actually Get Right

The nanoservice model, applied in production on Kubernetes clusters, attempts to preserve the isolation and modularity benefits of microservices while cutting out the operational costs that make them painful at small-to-medium scale.

The core insight is architectural rather than infrastructure-level. Instead of splitting services at the process boundary, with each service in its own Docker container communicating exclusively over the network, nanoservices split at the code module boundary, organized into layers: a networking layer, a core logic layer, and a data access layer. Each layer is independently testable and independently swappable, but they are compiled into a single binary.

This matters in a few concrete ways. Builds are faster because you are not waiting for multiple Docker builds and inter-service network configuration to line up. Circular dependencies become compiler errors rather than runtime surprises. When one core function needs data from another service, that data can be passed directly in memory rather than serialized, sent over a network, deserialized, and returned. The performance difference is not marginal.

Critically, this does not close off the option of deploying as microservices later. If a particular service grows large enough to warrant independent deployment, maybe it has distinct scaling requirements or a distinct team working on it, it can be extracted. The code is already structured to make that transition clean. You are not locked in either direction.

Asking a Better Question Than Monolith vs. Microservices

The monolith-vs-microservices question is usually the wrong question to lead with. The more useful question is: what granularity of modularization serves the team and product at this stage of the system’s life?

A small team building quickly should probably start with something closer to a nanoservice structure: clean module separation, well-defined layers, everything compiled together. This gives the developer experience of working on isolated, understandable pieces without the operational weight of managing multiple networked services. If the system grows and a genuine case emerges for pulling out a service, the modular structure makes that extraction tractable.

The teams that regret their architecture decisions are usually the ones that adopted microservices as an upfront commitment rather than as an option they might grow into. They took on the full operational complexity of the architecture before the system warranted it.

There is a related cost worth naming: microservices architectures are expensive to observe. Without investment in centralized logging, distributed tracing, and monitoring across all services, debugging becomes genuinely difficult. A network call fails somewhere in a chain of five services, and identifying where and why becomes a non-trivial investigation. Observability infrastructure is often an afterthought until the pain of not having it becomes too great to ignore.

Why Rust Makes This Argument Stronger

Most architecture discussions about microservices are language-agnostic, but they should not be entirely. Rust brings something specific to this conversation: the compiler as a collaborator rather than just a validator. When services are compiled together into a single binary, Rust’s type system and borrow checker enforce contracts between modules at build time. A bad interface, a circular dependency, an incorrect assumption about ownership, these surface as compile errors before they become production incidents.

This is a qualitatively different experience from working across service boundaries in dynamically typed languages, where the contract between services is enforced only at runtime, usually through documentation, convention, and hope. Rust makes the case for compiling services together stronger than it would be in a language with weaker static guarantees.

There is also the performance dimension. The latency cost of an in-process function call versus a network call is not trivial, especially as request complexity grows and the number of inter-service calls per request increases. Compiling services into a single binary eliminates that latency for cross-module communication, while Rust’s zero-cost abstractions ensure you are not paying hidden runtime costs elsewhere to achieve it.

Production-Readiness Is a Design Decision, Not a Final Step

One pattern worth internalizing is that production-readiness is not a state you arrive at after building; it is a set of decisions baked into how you structure code from the beginning. This means thinking about error handling across module boundaries early, building your logging and observability layer before you need to debug a production issue, and testing not just individual units but the interactions between layers.

The architecture you choose shapes how tractable all of this is. Clean module separation with explicit data access layers makes unit testing far more manageable because you can mock dependencies at the boundary. End-to-end atomic tests become more reliable when you are not introducing network uncertainty into every interaction. Deployment pipelines simplify when you are shipping one binary rather than coordinating releases across a constellation of services.

None of this is an argument against microservices in general. At sufficient scale, with sufficient team size and operational maturity, microservices solve real coordination problems. But for most web developers working on most systems at most stages of a product’s life, the more honest architecture discussion starts with modular code that compiles together, and evaluates the case for network boundaries only when a concrete, specific need for them emerges.

Speaking of building production-ready applications in Rust, we are running a live workshop with Francesco Ciulla where you will work through exactly these kinds of real-world engineering decisions. Using Claude and Codex as AI-native workflow tools, you will scaffold, debug, refactor, test, and ship a practical Rust application live. The workshop covers backend setup, AI integrations, retrieval and chat systems, and production-ready patterns; the kind of hands-on work that makes these architectural concepts concrete.

Build Production-Ready AI Applications with Rust, Claude, and Codex.

Claim Your Discounted Seat

This Week in the News

• 🚨 Anthropic pulls its newest AI model after the US government flags security concerns: Days after launch, Anthropic was ordered to disable Claude Fable 5 and Mythos 5 for all users over a possible jailbreak, letting it exploit cyber defences. The UK’s AI Security Institute reportedly found the model could breach systems 73% of the time in testing. This one’s worth watching closely, it’s tangled up with an ongoing Anthropic vs Trump administration lawsuit and raises real questions about how “too powerful to release” models get governed going forward.

• 🎨 Node-RED 5.0: the biggest editor overhaul in the project’s history: A built-in dark theme, split sidebars, pausable debug output, and Function nodes that can now call Link nodes and wait on a response. If you’ve been running Node-RED on autopilot for years, this release is the nudge to finally poke around the editor again. Just know it now demands Node.js 22.9+ minimum.

• 🪟 How Aave built a Liquid Glass component library for the web: Timed neatly with WWDC, Lochie Axon walks through recreating Apple’s Liquid Glass aesthetic as a cross-browser component library. Worth a look if you’ve been itching to bring that frosted, refractive UI trend into your own web projects without waiting on native support.

• 📅 Node.js is finally fixing its confusing release schedule: Starting October 2026, Node ditches the odd/even LTS dance for one major release a year, with version numbers matching the calendar year (27 in 2027, and so on). Every release becomes LTS, plus a new Alpha channel gives library maintainers a six month head start on breaking changes. If you only run LTS, this barely changes your life, which is exactly the point.

Beyond the Headlines

• 📝 How building an HTML-first site doubled a company’s users overnight: A genuinely great read on rebuilding a regulated utility’s broken React form using Astro, server redirects, and a tiny validation web component, no client-side state management in sight. The user numbers doubled the moment it shipped, and the takeaway about who gets bounced by heavy JS is one every product team should sit with.

• 🧩 How TypeScript actually infers type variables: If generic inference has ever surprised you in a way that felt like TypeScript was just messing with you, this breaks down the candidate collection and resolution process in painful detail. Dense, but it’s the kind of dense that actually resolves years of “why does TS do that” confusion.

• 👾 Can Chrome’s built-in AI play Zork? Not really: Raymond Camden hooks Chrome’s on-device Prompt API up to a JS port of Zork 1 and watches it wander in circles examining the same pile of leaves. A fun, low-stakes experiment that’s also a decent gut check on how far local, lightweight models actually get with multi-step reasoning.

• 🖌️ A Jane Street designer now prototypes in Claude Code more than Figma: Edwin Morris describes skipping mockups entirely and shipping working prototypes, including 2000+ line diffs, directly with Claude. The honest bit about what this does to code review and the “disposable prototype” framing is the part worth chewing on, not just the productivity win.

• 🧊 Draco.js: a pure JS mesh loader for three.js, by mrdoob himself: A from-scratch Draco decoder with no WASM dependency, plus a live demo to poke at. If your three.js pipeline has been fighting with Draco’s official loader, this is worth bookmarking.

The Developer Toolbox

📄 Extend UI: open source React components for document apps
PDF, DOCX, XLSX, and CSV viewers with bounding box citations, file upload, and e-signing, all ready to drop into agents or internal tools. If you’re tired of rebuilding document viewers from scratch every time a client wants “AI that reads my files,” this saves a real chunk of work.

📧 free-email-domains: a maintained list of every free email provider
Kiko has compiled and actively maintains a list of free email domains, perfect for screening signups and flagging spammy or throwaway addresses. Small utility, big quiet usefulness.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Meet the author

^{This article draws on insights from Magnus Larsson, an IT industry veteran who has worked in the field since 1986 and has consulted for major Swedish companies such as Volvo, Ericsson, and AstraZeneca. Earlier in his career, Magnus experienced firsthand the challenges of building distributed systems. Today, many of those challenges can be addressed with open-source tools such as Spring Cloud, Kubernetes, and Istio. Over the past eight years, he has helped customers adopt these technologies and shared his expertise through presentations and blog posts.}

There’s a moment in almost every distributed systems project where someone asks a completely reasonable question: why can’t we just use DNS? Every instance of a service registers under the same hostname, the DNS server hands back a list of IPs, clients cycle through them. It sounds elegant. It sounds like a solved problem. And for a while, especially in early-stage systems, it kind of works.

Then you scale up. Instances start crashing and restarting. Network partitions happen. You add a health check somewhere and realize DNS has no idea whether the IP it just returned belongs to a process that’s been dead for forty seconds. The elegant solution starts showing its seams.

This article is about why DNS-based service discovery breaks down in distributed systems, what the failure modes actually look like in practice, and how client-side discovery handles the chaos that DNS was never designed for.

Before we dig deeper into this, here’s a TL;DR you’ll need:

• 🔺 Angular v22 is Here

• ⚡ VoidZero Joins Cloudflare

• 🛠️ Copilot SDK is Now GA

• 📘 TypeScript Tips Everyone Should Know

• 🎬 CSS vs. JavaScript Animations

The DNS Round-Robin Promise

The idea behind round-robin DNS is straightforward. Multiple service instances register under the same DNS name. When a client resolves that name, the DNS server returns a list of IP addresses, one per instance, and the client works through them sequentially. The first request goes to the first IP, the second to the next, and so on. Load is distributed. Everyone goes home happy.

The problem is that this model is built on an assumption that quietly breaks in dynamic environments: that the list of IP addresses returned by DNS accurately reflects the set of healthy, reachable instances right now.

In a microservices environment, that assumption fails constantly.

What Actually Happens When You Try It

To make this concrete, consider a scenario where you scale a service to two instances and ask a dependent service what IPs it sees. DNS returns both. But when you start sending real traffic, you notice something strange: requests keep going to the same instance. The load balancing you expected isn’t happening.

This reveals one of DNS’s fundamental limitations as a load balancer: DNS clients don’t do per-request round-robin. They ask a DNS server once, get a list, try the first address that works, and then hold onto it. Caching is baked into how DNS works. It’s a feature for performance, but a liability when you need live instance awareness. Once a client finds a working address, it stops asking.

That’s problem one. Problem two is what happens when an instance disappears.

The Staleness Problem

DNS records have a time-to-live (TTL), and until that TTL expires, clients are working from a cached snapshot of the world. If an instance crashes, DNS doesn’t know. If a new instance starts up, DNS doesn’t know that either, not until someone updates the record and the TTL rolls over. In a system where instances come and go every few minutes, even a 30-second TTL creates meaningful windows of failure.

More critically, DNS has no concept of health. An IP address in a DNS response is just an IP address. It carries no information about whether the process listening there is actually ready to handle requests, whether it’s mid-restart, or whether it’s responding to health checks but silently dropping traffic due to a downstream issue. DNS cannot answer the question “is this instance okay?” because it was never designed to.

The Challenges DNS Can’t Address

When you enumerate what a robust service discovery mechanism actually needs to handle, the gap becomes clear.

New instances can appear at any time and need to be made available to clients quickly, not after a TTL expires. Existing instances can fail at any time, and failed instances need to be removed from rotation just as quickly. Some instances that fail temporarily might recover and should rejoin rotation; others won’t and should be permanently deregistered. New instances often have startup time as well. They can accept TCP connections before they’re actually ready to serve traffic, which means “is the port open” is a poor proxy for “is this instance ready.” And unintended network partitions, where a client loses connectivity to some instances but not others, can cause cascading failures if the discovery layer doesn’t account for them.

None of these are edge cases. They’re the normal operating conditions of a distributed system at any meaningful scale.

Client-Side Discovery: A Different Model

The approach taken by systems like Netflix Eureka flips the model. Rather than relying on DNS as a passive lookup table, it introduces an active registry that instances communicate with continuously.

When a service instance starts, it registers itself with the discovery server, not just its address but information about what it is. On a regular interval, it sends a heartbeat to signal that it’s still alive and healthy. If the heartbeats stop, the discovery server removes the instance from the registry after a configurable window. Clients, meanwhile, periodically fetch the current registry from the discovery server and cache it locally. When a client needs to make a call, it already has a fresh list of available instances and can select one without making a synchronous request to the discovery service for every call.

This architecture gets several things right that DNS doesn’t.

• Instance registration is active, not passive. A service has to deliberately register itself, and it has to keep proving it’s alive through heartbeats. An instance that crashes stops sending heartbeats and gets removed from the registry. There’s no waiting for a TTL.

• Readiness is separable from availability. A service can control when it registers itself, after initialization is complete, after database connections are established, after whatever startup work needs to happen. The registry reflects intent, not just the existence of a listening port.

• Clients are participants, not observers. Because clients cache the registry locally and refresh it on a schedule, they can make load-balancing decisions with reasonably current information, and they do so per-request rather than per-connection. This is what produces actual round-robin behavior in practice.

• The system degrades gracefully. If the discovery server itself goes down, clients continue operating from their local cache. They can still reach instances that were registered before the outage. New instances can’t register and deregistered instances won’t be removed, but existing traffic keeps flowing. If a DNS server goes down, resolution fails entirely.

The Propagation Question

One nuance worth understanding is that client-side discovery still has propagation delay. It’s just controlled and predictable rather than dependent on TTLs set by infrastructure you may not own.

When an instance spins up and registers, clients that have already fetched the registry won’t know about it until their next refresh cycle. Similarly, when an instance goes down, there’s a window between the last heartbeat and the next client cache refresh during which they might try to call an address that no longer works. This is why production systems built on client-side discovery pair it with retry logic and circuit breakers. The discovery layer reduces the failure surface significantly, but it doesn’t eliminate the need for resilience patterns at the call level.

The important difference from DNS is that these windows are tunable. In a development environment, you might configure clients to refresh every five seconds and instances to send heartbeats just as frequently. In production, you’d balance freshness against the load of constant registry polling. DNS gives you no such control.

What This Means in Practice

The practical implication of all this is that service discovery isn’t primarily a load balancing problem. It’s a membership problem. The question being answered is “who is currently in this service’s pool of healthy instances?” and DNS was built for a world where membership changes on a timescale of hours or days, not seconds or minutes.

Client-side discovery systems treat membership as a live, continuously updated data structure. Instances opt in by registering and staying registered through heartbeats. Clients subscribe to changes in that membership by periodically refreshing their local view. The discovery server is the source of truth, but it’s a source of truth that expects the world to change constantly and is designed accordingly.

When you start thinking about service discovery through this lens, as a membership system rather than a name resolution system, the limitations of DNS become obvious. DNS is a remarkably well-engineered solution to the problem it was designed to solve. Service discovery in distributed systems is a different problem entirely.

Takeaways

• DNS round-robin doesn’t actually round-robin. Clients cache working addresses and stick with them. The per-request load distribution you expect doesn’t happen in practice.

• DNS has no health awareness. An IP in a DNS response carries no signal about whether that instance is alive, ready, or functional. Health and availability are entirely separate concerns that DNS has no mechanism to represent.

• Instance registration needs to be active, not passive. Robust service discovery requires instances to continuously prove they’re alive, not just appear in a record once. Heartbeat-based registration is the mechanism that makes deregistration automatic and timely.

• Propagation delay exists in all discovery systems, but client-side discovery makes it controllable. Understanding the refresh window and pairing discovery with retry logic is the path to resilient service-to-service communication.

• The discovery server is not a single point of failure if clients cache. Because clients maintain local copies of the registry, discovery server downtime degrades gracefully rather than catastrophically, a significant practical advantage over centralized DNS in high-availability requirements.

Service discovery isn’t glamorous infrastructure. It’s the kind of thing that works invisibly when it’s right and causes deeply confusing failures when it’s wrong. Getting the model right from the start saves a lot of painful debugging later.

This Week in the News

• ⚡ VoidZero Joins Cloudflare: Big news: Cloudflare has acquired VoidZero, the team behind Vite, Vitest, Rolldown, and Oxc, and has pledged $1 million to an independent Vite ecosystem fund. Evan You was frank about the reason: monetizing open-source tooling has proven extremely hard, despite Vite’s enormous adoption. Vite stays MIT-licensed and vendor-neutral, but Cloudflare now has its hands on the plumbing of a large chunk of the modern web. Worth watching closely.

• 🔺 Angular v22 is Here: The signal-first era is no longer a roadmap promise. Signal Forms and resources are now stable, OnPush is now the default change detection strategy, and the HTTP client uses Fetch by default. This is a consolidation release: the experiments are over, and you’re looking at the Angular team’s considered view of how production apps should be built in 2026. If you’ve been waiting for the right time to migrate, that time is now.

• ☠️ Red Hat’s npm Namespace Got Backdoored: A compromised Red Hat employee GitHub account was used to inject malicious workflows into three RedHatInsights repositories, with OIDC tokens publishing backdoored package versions that carried valid SLSA provenance attestations, making them look completely legitimate. The worm self-propagates using stolen npm tokens, bypassing 2FA to republish backdoored versions of other packages autonomously. This one is nasty. If you ran npm install on anything under @redhat-cloud-services after June 1st, rotate everything.

• 🧡 What’s New in Svelte: June 2026: This month brings better forms, new long-lived remote query APIs, and TypeScript 6 support in language-tools. The standout addition is .live(...), a new query function that makes pulling real-time server data dramatically cleaner. Svelte’s changelog keeps getting better without the drama. Quiet excellence.

• 🤖 State of AI 2026: Devographics surveyed 7,258 developers on AI in their workflows, and the numbers are striking. The average proportion of AI-generated code has jumped from 28% in 2025 to 54% this year, with the 75%+ segments seeing the highest growth. ChatGPT leads in raw usage, but Claude tops the charts for positive sentiment and is the model developers are most willing to actually pay for. The full dataset is worth digging into; pull up the interactive charts.

• 🛠️ Copilot SDK is Now GA: You can now embed GitHub Copilot’s agentic engine directly into your own applications and developer tools, with access to planning, tool invocation, file edits, streaming, and multi-turn sessions, no need to build your own orchestration layer. Support spans Node.js, Python, Go, .NET, Rust, and Java. This is less a Copilot story and more a platform story; GitHub is positioning itself as the runtime for AI-native dev tooling.

Beyond the Headlines

• 🧠 The Orchestration Tax: Addy Osmani names something most of us are quietly struggling with: spinning up more agents doesn’t mean you’re doing more. Your cognitive bandwidth doesn’t parallelize. All the judgment to actually steer agents and merge the code they produce still has to route through exactly one serial processor, which is you. Feeling busy is not the same as being productive.

• 📘 TypeScript Tips Everyone Should Know: This is a compact, no-nonsense reference of TypeScript patterns worth bookmarking. Solid for both onboarding newer devs and as a quick refresh, the kind of thing that pays dividends when you actually internalize it rather than skim it once and forget.

• 🌍 A Functional Taxonomy of World Models: Fei-Fei Li and the World Labs team cut through the noise around “world models” and actually define what the term means across different fields. Computer vision, robotics, reinforcement learning, and generative AI all claim to be building world models, and each means something quite different: renderers, simulators, planners. If you care about where AI is actually heading beyond LLMs, this is essential reading.

• ⏳ The Best Loading States Are No Loading States: Applications end up with skeletons, spinners, shimmer effects, suspense fallbacks, UI whose only job is to occupy the space where data should eventually appear. We’re all spending a surprising amount of time solving the same problem, and none of it is really product work. This is a sharp essay that argues we’ve been thinking about this backwards, and the web already had the answer before SPAs came along.

• 🎬 CSS vs. JavaScript Animations: Josh Comeau compares the same animations built across several different strategies and examines the performance implications firsthand, and there’s some interesting nuance in the results. Not the take you might expect. This is a required reading before you reach for a JS animation library by default.

• 🔁 When AI Builds Itself: The Anthropic Institute published something worth sitting with: a look at their actual progress toward recursive self-improvement, with internal data included. Anthropic engineers today ship 8x as much code per quarter as they did between 2021 and 2025, and a growing share of the AI development cycle is now being delegated to AI systems themselves. They’re careful to say recursive self-improvement isn’t inevitable, but the framing is unusually candid.

The Developer Toolbox

✍️ Hocuspocus

If you need to add real-time collaborative editing to an app, Hocuspocus from the Tiptap team is the cleanest path there. It’s a plug-and-play collaboration backend based on Y.js, handling conflict resolution via CRDT so you don’t have to think about merge logic. Works offline, syncs on reconnect, and pairs naturally with Tiptap, but it’s flexible enough for other editors too.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.

Grow your Mac app with Setapp. Get around 30K unique impressions in the first days after your app’s release

Setapp makes sure your app isn’t just listed, but seen. Plus, we handle the stuff you don’t like: distribution, licensing, billing, taxes, and customer support. You build great software; we bring you revenue and valuable feedback to help your app grow. Hope is not a growth strategy. Join Setapp. Share your app!

Meet the author

This piece is written by Rodrigo Lobenwein.

With a background in full stack development across .NET and React, Rodrigo leads a team of senior developers and QA specialists, focusing on the architectural decisions that sit between engineering and product.

His work centers on helping teams develop the judgment to make the right technical calls not just follow the right frameworks.

React developers learn a reliable reflex early on: update state, let the component re-render, trust the output. That model still holds. The friction starts when the work behind a state update grows large enough for users to actually feel it: a search input that lags on every keystroke while thousands of rows refilter behind it, a tab change that completes instantly in the code but arrives just late enough to make the UI feel sluggish.

The instinct at that point is to reach for useMemo or useCallback. Those tools still matter, but they address unnecessary work. Sometimes the problem is different: React is being asked to treat urgent and non-urgent work as if they carry equal weight. Since version 18, the framework has had a better vocabulary for that distinction, and React 19 extends it further. Developing an intuition for when to apply it is what this piece is about.

Before we dig deeper into this, here’s a TL;DR you need:

• 🤖 Google I/O 2026 pushes deeper into the agentic AI era

• 📚 Storybook 10.4 brings improvements for component-driven development

• 🧩 Designing component architecture for React Server Components

• 🚀 Migrating from Express to Next.js with AI agents

• 🗺️ What clustering map tiles can teach us about problem solving

Not Every Update Has the Same Urgency

Consider a search screen. A user types a character into an input. Two things happen simultaneously: the text field shows the new value, and the results list re-renders against the new query.

Those updates are related but not equally pressing. The input sits directly under the user’s fingers — any delay there registers immediately as a broken experience. The results list matters too, but a brief lag is far less perceptible than a laggy cursor. Most users won’t notice 100ms of stale results. They will notice 100ms of input latency.

Instead of thinking only in terms of “state changed, render now,” concurrent React asks you to think about which update is urgent and which can wait for a better moment.

That distinction is the conceptual foundation of concurrent rendering.

Figure 1 - The two tiers of update urgency in concurrent React

What Automatic Batching Actually Solved

Before transitions make sense, it helps to separate them from automatic batching, which is an adjacent improvement that solves a different problem.

In React 17, batching was largely confined to synchronous React event handlers. Multiple state updates inside a Promise callback, a setTimeout, or a fetch response were often processed as separate renders. More renders than necessary, without much upside.

The createRoot API in version 18 extended automatic batching across more update sources: timers, Promise handlers, and most async callbacks. Many apps shed redundant render cycles without changing a single component.

Batching is a reduction in render quantity. Transitions are about render priority. Even with batching in place, a single batched update that includes expensive list rendering can make an input feel sticky. Batching has no way to distinguish which part of that update the user is waiting on. Transitions provide that signal.

Marking Lower-Priority Work with startTransition

The startTransition API lets you label a state update as non-urgent. “Non-urgent” does not mean “unimportant” — it means React does not need to hold up higher-priority feedback to process it first.

In a search interface, the pattern looks like this:

const handleOnChange = (event) => {

setInputValue(event.target.value); // urgent: runs first

startTransition(() => {

setQuery(event.target.value); // deferred: can wait

});

};

Figure 2 — Without transitions, an expensive list render blocks the input. With transitions, the input stays instant and list work is interruptible.

The transition wraps the update that causes the expensive rendering, not the expensive code itself. React is not being told to skip the work; it’s being given the context to sequence it correctly.

A reliable heuristic: reach for a transition when a state update can trigger a large render, and the user does not need to see the result of that update instantaneously. Filtering a long list is a candidate. Updating the visible value in an input is not.

When the UI needs to acknowledge that transition work is still in progress, useTransition returns both pieces:

const [isPending, startTransition] = useTransition();

Use isPending for lightweight signals: dimming stale content, showing a small spinner. Resist the urge to let it take over the layout, its value is in supporting the interaction, not replacing it.

When useDeferredValue Fits Better

Both startTransition and useDeferredValue address the same class of problem. The choice between them turns on where you have control in the component tree.

Figure 3 — The decision comes down to code ownership. Both APIs produce equivalent scheduling outcomes

When the component owns both the input and the expensive update, startTransition is usually the cleaner solution:

function SearchPage() {

const [inputValue, setInputValue] = useState(”“);

const [query, setQuery] = useState(”“);

const [isPending, startTransition] = useTransition();

const handleOnChange = (event) => {

const nextValue = event.target.value;

setInputValue(nextValue);

startTransition(() => { setQuery(nextValue); });

};

return (

<>

<input value={inputValue} onChange={handleOnChange} />

<Results query={query} dimmed={isPending} />

</>

);

}

The component has direct access to both setState calls, so it can be explicit about which one should yield.

When the value arrives from outside, from a parent, a form library, route state, or a shared component, the results component can’t reach the original setState. It can, however, choose to render against a deferred version of the value:

function ResultsPanel({ query }) {

const deferredQuery = useDeferredValue(query);

const isStale = query !== deferredQuery;

const items = useMemo(

() => filterLargeList(deferredQuery),

[deferredQuery]

);

return <Results items={items} dimmed={isStale} />;

}

Here, query updates immediately in the parent; deferredQuery trails behind when rendering is busy. The expensive filtering follows the deferred value, so the input stays responsive regardless of how long the results take.

How This Changes Component Design

Concurrent rendering does not mean every piece of state needs a priority label. Most updates are cheap, and most components need no transitions whatsoever.

The practical design question is more targeted: what part of this interaction must feel instant, and what part can follow slightly behind? Asking it tends to clarify both component boundaries and state placement. State driving the element the user is actively touching belongs on the urgent path. State driving a large subtree, expensive filtering, or a complex visual transformation is often a better fit for transition work.

One underrated benefit of this model is interruptibility. Transition rendering can be abandoned. If a user types another character before the previous results render finishes, React discards the stale render and restarts with the latest input. That’s a meaningful improvement over older setTimeout-based workarounds, where React had no clear signal about which work was still relevant.

The Shift Worth Internalizing

The APIs themselves are small. startTransition wraps a state update. useDeferredValue returns a lagging version of a value. The more durable change is in how you reason about responsiveness.

Older React code tends to treat rendering as a single block: state changes, render fires, UI reflects the result. Concurrent React asks for a slightly different mental model — one closer to how interface designers think about interaction. The thing under the user’s control responds first. Work that improves the screen but doesn’t need to be immediate follows behind.

React performance is not only about preventing work. It is also about sequencing work so the app feels responsive where it matters most.

Key Takeaways

• React 18 expanded automatic batching via createRoot, cutting unnecessary renders across async update sources.

• startTransition schedules a state update as lower priority without preventing it from running.

• useTransition returns [isPending, startTransition], letting you give subtle in-progress feedback while expensive work continues.

• useDeferredValue fits when a component receives a value from outside and can tolerate rendering against a slightly older version.

• Transition rendering is interruptible — stale work is abandoned when newer, more urgent updates arrive.

• The concurrent model reframes performance: not only as avoiding unnecessary work, but as sequencing necessary work by urgency.

Want to read more on the topic? React and React Native, Sixth Edition covers React 19 and React Native from the ground up.

This Week in the News

• 🤖 Google I/O 2026 pushes deeper into the agentic AI era: Google used I/O 2026 to double down on AI across its entire ecosystem, with major updates to Gemini, Search, developer tools, and agent-based workflows. The company introduced new models like Gemini Omni and Gemini 3.5 Flash, expanded its agent platform, and continued reshaping Search around AI-powered experiences. The bigger theme was clear: Google is moving beyond AI as a feature and positioning it as the foundation across products, workflows, and developer tooling.

• 📚 Storybook 10.4 brings improvements for component-driven development: Storybook 10.4 introduces a range of updates aimed at improving the developer experience around building, testing, and documenting UI components. The release continues Storybook’s focus on making component-driven development more efficient, with enhancements across workflows, tooling, and framework support. As frontend applications grow in complexity, tools like Storybook are becoming increasingly important for maintaining consistency and speeding up UI development.

• 🚀 Astro 6.4 goes full Rust on Markdown: Astro 6.4 joins the Rust rewrite club with Sätteri, a new Markdown processor that cut over a minute off real-world build times. It’s opt-in for now via the new markdown.processor API, but the team has flagged it as the likely future default, migration cost being the remark/rehype plugin compatibility.

• 🤖 Claude Opus 4.8 drops as an incremental but meaningful upgrade: Better benchmark scores, sharper agentic judgment, and notably improved honesty (4× less likely to let code flaws slip by unremarked). Pricing stays the same. Also shipping alongside it: effort controls on claude.ai, and a “dynamic workflows” feature in Claude Code that can spin up hundreds of parallel subagents for codebase-scale tasks.

• 🌐 Web platform catches up on quality-of-life: April’s Baseline digest brought some solid platform wins: contrast-color() auto-picks readable text against any background, Math.sumPrecise() fixes floating-point drift in array sums, the <search> element now hands you an ARIA landmark for free, and ARIA attribute reflection means cleaner element.ariaExpanded syntax over setAttribute.

Beyond the Headlines

• ⚡ How is Linear so fast? A technical breakdown: Linear has become the benchmark for fast, responsive web applications, and this deep dive explores the engineering decisions behind that experience. From frontend architecture to rendering strategies and performance optimizations, the article breaks down the techniques that help the product feel almost instantaneous. The broader lesson is that performance is rarely the result of a single breakthrough. It comes from dozens of deliberate decisions across the stack, all working together to reduce friction and keep users in flow.

• 🧩 Designing component architecture for React Server Components: React Server Components change more than just where code runs. They also influence how applications are structured and how responsibilities are divided between components. This article explores architectural patterns for organizing components in an RSC-based application and avoiding common pitfalls. As more frameworks embrace server-first rendering, understanding these patterns is becoming increasingly important. The challenge is no longer just building components, but deciding which ones belong on the server and which ones truly need to run on the client.

• 📄 Bringing AI workflows to PDF-heavy applications: As AI agents become more capable, one challenge remains consistent: documents. This article explores how Foxit’s MCP Server connects AI systems with PDF workflows, enabling tasks such as document analysis, extraction, and processing without requiring developers to build custom integrations from scratch. The bigger trend is the rise of infrastructure that helps AI agents interact with existing business systems. Rather than generating text in isolation, agents are increasingly being equipped to work with the documents and workflows that power day-to-day operations.

• 🚀 Migrating from Express to Next.js with AI agents: This case study explores using AI agents to help migrate an application from Express to Next.js. Rather than focusing solely on code generation, it examines how agents can assist with larger engineering tasks such as understanding existing architecture, planning migrations, and implementing changes across a codebase. The interesting takeaway is that AI is increasingly being used as a collaborator on complex development projects. The challenge is no longer whether AI can write code, but how effectively it can help developers navigate and transform existing systems.

• 🗺️ What clustering map tiles can teach us about problem solving: In this post, Cassidy Williams walks through the challenge of clustering map tiles and the thought process behind solving it. Rather than focusing solely on the final solution, the article highlights the experimentation, trade-offs, and iterative thinking that go into tackling a seemingly simple problem. It’s a good reminder that software engineering is often less about finding the perfect algorithm and more about breaking complex problems into manageable pieces and refining solutions along the way.

The Developer Toolbox

• 🔥 Build reactive web apps without a framework runtime: Modern frontend frameworks often trade simplicity for abstractions. Flue takes a different approach, offering a reactive UI framework that focuses on minimal overhead, direct DOM updates, and a lightweight development experience. The project aims to deliver fine-grained reactivity without the complexity or runtime costs typically associated with larger frameworks. If you’re interested in exploring alternative approaches to building fast, reactive web applications, Flue is worth a look.

• ⌨️ Handle keyboard shortcuts with minimal overhead: Keyboard shortcuts can quickly become messy as applications grow. Tinykeys is a lightweight JavaScript library that makes it easy to define and manage keyboard shortcuts with a simple, intuitive API. At under 1 KB, it supports complex key combinations and sequences without adding unnecessary weight to your application. If you’re building power-user features, command palettes, or productivity-focused interfaces, Tinykeys offers a clean way to handle keyboard interactions.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.

That landscape has changed. Modern HTML and CSS now handle far more than layout and decoration. They can respond to form state, respect system preferences, manage disclosure patterns, animate page transitions, create motion paths, style modal backdrops, and support accessible behavior that developers previously had to rebuild from scratch. The question is no longer “Can JavaScript do this?” because, of course, it can. The better question is “Should JavaScript be responsible for this?”

A CSS-first mindset does not mean rejecting JavaScript. It means giving the browser a fair chance before adding another dependency, state handler, event listener, or UI library. It asks developers to start with semantic HTML, layer CSS for presentation and interaction, and reserve JavaScript for the work it is uniquely good at: data fetching, complex application logic, persistence, coordination across systems, and genuinely dynamic behavior.

That small shift can change the quality of a frontend codebase. Interfaces become lighter, easier to reason about, more resilient when something fails, and often more accessible by default. For intermediate developers, this is one of the most useful habits to build: not writing less code for the sake of minimalism, but choosing the browser-native path when it gives users a better result.

Before we dig deeper into this, here’s a TL;DR you need:

• 🦀 Bun’s massive Rust rewrite reignites the JavaScript tooling conversation

• 🔒 TanStack’s supply chain compromise shows how fragile npm security still is

• 🌐 Chrome and Edge explore a native <install> element for PWAs

• 🔒 Shai Hulud returns with another package supply chain hit

• 🎥 TanStack Start enters the framework race with a different philosophy

• 🪶 Critical 8.0 brings CSS performance back to first paint

The cost of reaching for JavaScript too early

JavaScript is powerful, but power has a cost. Every script has to be downloaded, parsed, compiled, and executed. Every custom interaction adds more behavior to maintain. Every dependency introduces another layer of updates, bundle impact, and possible failure. On a fast machine and a strong connection, those costs may feel invisible. On a slower device, a busy network, or a page already carrying analytics, ads, and third-party widgets, they become much easier to feel.

The issue is not that JavaScript is bad. The issue is that many teams use it as a default even when the browser already has the behavior built in. A simple accordion becomes a component with state. A modal becomes a focus-management exercise. A navigation highlight becomes a DOM query. A theme switcher becomes a script-first feature before CSS has been allowed to handle the visual logic.

CSS is becoming contextual, not just decorative

One of the most important changes in modern CSS is that it can respond to context. The :has() selector is a good example. For a long time, CSS could style children based on parents, descendants based on ancestors, and siblings in limited directions, but it struggled with parent-level conditions. Developers often added JavaScript just to say, “Style this container differently when something inside it is checked, active, hovered, or present.”

That kind of logic now fits naturally into CSS. A fieldset can react when a checkbox inside it is selected. A navigation item can show an indicator only when it contains a submenu. A card list can blur non-hovered cards when one card is active. A layout can switch when a form control changes state. These are visual responses to visual conditions, which makes CSS a better home for them than JavaScript.

The real takeaway is not simply that :has() is useful. It is that CSS is moving closer to how designers and developers think about interfaces. Components rarely exist in isolation. Their styling depends on state, nearby elements, available space, user preferences, and interaction context. The more CSS can express those relationships directly, the less we need to create artificial classes or scripts just to bridge the gap.

Native elements carry behavior we often forget to value

A CSS-first approach becomes even stronger when paired with semantic HTML. Elements such as <dialog>, <details>, and <summary> are not just markup conveniences. They carry interaction behavior that many teams have spent years recreating.

Take modals. A custom modal usually needs background blocking, focus handling, Escape-key behavior, ARIA wiring, open and close logic, and backdrop styling. The native <dialog> element handles much of this through the browser. With showModal(), the page gets modal behavior without a large custom system. CSS can then style the dialog and its ::backdrop, while a small amount of JavaScript handles the moment it opens.

Accordions tell a similar story. The <details> and <summary> elements provide disclosure behavior without building state from scratch. They work with keyboard interaction, keep content structured, and remain understandable even when CSS enhancements are unavailable. When multiple details elements share a name, they can behave like a grouped accordion where opening one closes another. That is a meaningful reduction in custom logic.

Accessibility improves when the browser keeps its job

Many accessibility problems come from replacing native behavior with custom behavior and then forgetting to rebuild all the pieces users rely on. A div that behaves like a button still needs keyboard support, focus styles, roles, states, and expected interaction patterns. A custom accordion still needs to communicate its expanded state. A custom modal still needs to manage focus without trapping users in awkward ways.

CSS-first and HTML-first thinking reduces that risk. Native controls already know a lot about input methods, assistive technologies, system preferences, and user expectations. A range input can be dragged, focused, and adjusted with the keyboard. A summary element can be opened without a custom click handler. A dialog can announce itself with the right labeling when structured properly.

This does not remove responsibility from developers. Accessibility still requires care. Motion should respect prefers-reduced-motion. Theme choices should preserve contrast. Generated content should not be the only place important information exists, because pseudo-elements are not always announced. A CSS-generated counter, for example, may need an accessible label or equivalent text in the markup.

Progressive enhancement is back in a practical way

Modern CSS features arrive at different speeds across browsers. That can make teams cautious, especially when they remember older eras of painful browser inconsistencies. The healthier approach is not to avoid new CSS entirely. It is to use progressive enhancement deliberately.

Some features are safe because unsupported browsers simply fall back to a usable experience. Smooth scrolling can fall back to normal anchor jumps. Accordion animations can fall back to instant open and close behavior. A masked comparison slider can still expose a native range input with a simpler presentation. View transitions can be ignored by unsupported browsers while navigation continues to work.

Feature queries such as @supports help developers layer enhancements only where browsers understand them. User preference queries such as prefers-color-scheme and prefers-reduced-motion let sites adapt to the person using them rather than forcing one visual experience on everyone. This is not just technical neatness. It is a more respectful way to build for a web that runs across different devices, settings, and constraints.

Motion needs purpose, not just possibility

CSS can now create polished motion without JavaScript timers or heavy libraries. Infinite logo sliders, animated borders, view transitions, motion paths, and scroll-driven effects can all be handled mostly or entirely through CSS. That is exciting, but motion should earn its place.

A partner logo strip that moves continuously may add energy, but it should pause on hover or focus so users can inspect it. Page transitions can make navigation feel smoother, but they should not slow users down or become disorienting. A glowing animated border may draw attention to a feature card, but the interface should still feel calm when motion is reduced.

This is where CSS gives developers a useful advantage. Animations can be expressed declaratively, paused with state selectors, and disabled through media queries. Rather than manually coordinating timers, listeners, and cleanup, the browser can manage the animation lifecycle. That usually leads to smoother performance and simpler code.

The future frontend stack may be smaller than we expected

The frontend ecosystem often moves by adding layers. More state management, more rendering strategies, more build tools, more component abstractions. Many of those tools solve real problems, especially in application-heavy environments. But the browser itself has also been moving forward, and sometimes our habits have not caught up.

A smaller stack does not mean a less capable interface. It can mean choosing CSS variables for theming before inventing a theme engine. It can mean using prefers-color-scheme before writing theme detection logic. It can mean using <dialog> before importing a modal package. It can mean using scroll-margin-top before writing scroll offset JavaScript. It can mean allowing CSS counters to number content instead of maintaining numbers by hand.

The strongest teams will not be the ones that avoid JavaScript. They will be the ones that know when not to spend it. JavaScript should still handle persistence for a saved theme choice, fetch fresh data, coordinate complex interactions, and power application logic. But it should not automatically inherit every small UI responsibility simply because it can.

Takeaways

Modern CSS is no longer just a styling layer. It can express state, context, user preferences, motion, and responsive interaction patterns that once required JavaScript. Intermediate developers should treat CSS and semantic HTML as active parts of interface architecture, not just the final presentation pass.

The best use of JavaScript is intentional. Reach for it when the interface needs data, persistence, complex logic, or behavior the browser cannot provide on its own. For many everyday UI patterns, native HTML and CSS now provide a lighter, more accessible, and more maintainable starting point.

Progressive enhancement is the safest way to adopt newer features. Build a solid baseline first, then layer modern selectors, animations, masks, transitions, and preference-aware behavior where support allows. Users get a functional experience everywhere, and a richer one in capable browsers.

The real mindset shift is simple: before adding script, pause and ask whether the browser already understands the job. More often than many developers expect, the answer is yes.

This Week in the News

• 🤖 Google open-sources Ax for distributed AI agents: Google has open-sourced Ax, a distributed runtime designed for building and coordinating AI agents across systems. The project focuses on managing agent execution at scale, reflecting growing interest in infrastructure for multi-agent workflows rather than standalone AI interactions.It’s another sign that the AI ecosystem is shifting from individual prompts toward orchestrated agent-based systems.

• 🧨 Bun’s Rust rewrite finally lands: Bun’s long-discussed Rust rewrite has now been merged, which gives the runtime another big moment in the JavaScript tooling conversation. The interesting part is not only the rewrite itself, but the debate around how it was produced. With AI-ported code under scrutiny, this becomes a useful reminder that speed still needs engineering taste, review discipline, and trust in the codebase. For developers, Bun remains one of the most exciting projects to watch, but this merge also shows how closely the community is now examining the way modern tooling gets built.

• 🌐 Browsers may soon get a trusted PWA install button: Chrome and Edge are exploring a new <install> HTML element that would let browsers render a trusted install button for PWAs. That might sound like a small interface detail, but it points to a bigger shift in how seriously browsers want to treat installable web apps. PWA adoption has always had a discoverability problem. A native, browser-controlled install element could make the experience feel clearer, safer, and more consistent for users, while giving developers a cleaner path to promote app installation without relying on custom prompts.

• 🎥 Fireship explains how one PR hijacked the npm registry: The npm ecosystem had another uncomfortable security lesson, and Fireship’s breakdown captures why this matters for everyday developers. A single compromised or malicious pull request can ripple through the dependency graph faster than most teams can react. JavaScript’s strength has always been its massive open ecosystem, but that same scale makes supply chain security everyone’s problem.

• 🔒 Shai Hulud returns with another package supply chain hit: Shai Hulud struck again this week, affecting hundreds of packages and adding another serious entry to the JavaScript supply chain security story. At the same time, node-ipc was also infected with a credentials stealer, which makes this feel less like an isolated scare and more like a pattern developers need to plan around. The practical question for teams is no longer whether package compromise can happen. It is how quickly they can detect, contain, rotate credentials, and recover when it does.

Beyond the Headlines

• 📺 TanStack Start takes its shot at the framework conversation: Tanner Linsley’s conversation on TanStack Start is worth watching because it is a candid look at what it takes to compete in a space where Next.js already shapes many developers’ expectations. TanStack has earned trust through focused, composable tools, and Start is trying to bring that same philosophy into full-stack app development. The bigger story is how much appetite still exists for frameworks that give developers more control without asking them to give up modern conventions.

• 🧩 Browser engines quietly patch the web for popular sites: Some browsers ship built-in tweaks for specific popular sites when those sites do not render correctly by default. Firefox and Safari both do this, which says a lot about the messy reality behind the “web standards” ideal. Developers often talk about browser compatibility as though it is only about specs, but the web also runs on pragmatism. When a major site breaks, browser teams sometimes bend a little to preserve the user experience. It is a fascinating glimpse into the invisible maintenance work that keeps the modern web usable.

• 🧠 The limits of native code deserve a closer look: Artem Loenko’s piece on native code lands at a useful time, especially as more web developers think about performance through the lens of Rust, WebAssembly, and lower-level tooling. Native code can be powerful, but it is not a magic escape hatch. Complexity, portability, safety, developer experience, and maintenance still matter. The best engineering choices usually come from knowing where native code helps, where it complicates things, and where higher-level tools already do the job well enough.

• 🌱 Open source projects can die in surprisingly ordinary ways:: This piece is a sharp reminder that open source projects do not always fail because of dramatic technical problems. Sometimes they fade because maintainers burn out, governance is unclear, onboarding is painful, or the project quietly stops feeling worth the effort. For developers who depend on open source every day, it is worth reading with empathy. Healthy projects need more than stars, downloads, and GitHub activity. They need people, process, trust, and a path for new contributors to become part of the work.

• 🧬 How Node.js and V8 keep each other working: Joyee Cheung’s deep dive into Node.js and V8 is a great read for anyone who wants to understand the machinery behind the runtime we use so casually. Node’s relationship with V8 is not a simple dependency story. It is an ongoing coordination effort across APIs, internals, performance work, compatibility, and release timing. This is the kind of behind-the-scenes engineering that rarely gets the spotlight, but it directly shapes what JavaScript developers can build and how reliably their apps run.

Practical AI for Working Developers

AI is moving fast, and for a lot of developers, keeping up still feels like learning through trial and error.

BuildWithAI is Packt’s newsletter for engineers who want to move beyond AI headlines and start using it in real projects.

Backed by Packt’s 7,000+ tech books, courses, and expert resources across 1,000+ technologies, each issue brings you practical workflows, carefully chosen resources, and implementation guidance you can actually apply. Subscribe here.

The Developer Toolbox

• ⚡ Critical 8.0: Addy Osmani’s Critical 8.0 helps extract and inline above-the-fold CSS into HTML, which makes it useful for anyone still paying attention to real-world page speed. Performance work often gets buried under bigger framework conversations, but rendering fast still matters. Critical is a reminder that some of the highest-impact optimizations are practical, focused, and close to the browser’s first paint. For teams working on content-heavy sites, landing pages, or performance-sensitive web apps, this is a tool worth revisiting.

• 🗓️ SVAR Calendar brings a flexible calendar component across frameworks: SVAR Calendar offers a calendar component for React, Svelte, and Vue, with an MIT-licensed core and a commercial version for extended use cases. Calendar UI is one of those deceptively hard pieces of product development. It looks familiar until you need recurring events, custom views, localization, styling, and framework compatibility. SVAR’s cross-framework approach makes it interesting for teams that want a polished calendar foundation without building every interaction from scratch. The live demo is worth a quick look.

A cube appears on screen. A light illuminates the scene. The camera moves smoothly. An animation loop runs continuously.

At that stage, the experience feels manageable. The structure seems straightforward: create a scene, add geometry, configure lighting, and render continuously.

The early feedback loop is rewarding because visible progress happens quickly. A functioning 3D scene can come together in relatively little code, which creates the impression that the difficult part has already been solved.

But complexity in Three.js rarely appears immediately.

It emerges gradually through interaction between systems: lighting affects material perception, camera positioning changes spatial readability, shadows introduce rendering overhead, responsiveness alters composition, animation timing affects scene coherence, and asset complexity impacts performance.

The difficult part is not rendering the first object.

The difficult part is maintaining coherence as the scene evolves.

This is why many impressive Three.js demos struggle to become stable, scalable product experiences. The challenge is rarely the first rendered frame. The challenge is managing the growing interaction between rendering, animation, lighting, responsiveness, and scene organization over time.

Before we get into it, here’s a sneak peek of this week’s highlights:

• 🛡️Next.js patches 13 vulnerabilities that teams should not leave to the firewall

• 🏗️ Anthropic’s Colossus deal puts AI infrastructure back in the spotlight

• 🤖 AgentField turns multiple coding agents into one TypeScript workflow

• 🧬 React2Shell shows how curiosity can become an ecosystem-level security story

• ⚛️ React Server Components in five minutes

Small scenes feel deceptively manageable

Most Three.js projects begin with a minimal scene setup: a scene, a camera, a renderer, geometry, and a light source.

At this stage, the mental model feels clean and predictable. Each component appears isolated and understandable. The renderer draws frames. The camera controls perspective. Geometry defines visible structure. The scene acts as the container that brings everything together.

A basic setup often looks like this:

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(
75,
window.innerWidth / window.innerHeight,
0.1,
1000
);

const renderer = new THREE.WebGLRenderer();

renderer.setSize(
window.innerWidth,
window.innerHeight
);

document.body.appendChild(
renderer.domElement
);

At this point, the scene feels conceptually simple because very few systems are interacting simultaneously. The objects are few, the camera is predictable, and the renderer has a clear job: draw what exists in the scene from the camera perspective.

Then geometry is added. The code still looks approachable because geometry, material, and mesh map neatly to what appears on screen:

const geometry = new THREE.BoxGeometry();

const material =
new THREE.MeshStandardMaterial({
color: 0x00ff00
});

const cube = new THREE.Mesh(
geometry,
material
);

scene.add(cube);

The result feels immediate and satisfying. Something visible exists on screen. The rendering pipeline works. The scene responds correctly.

This early success is useful, but it can also mislead. Developers often assume that scaling a Three.js project simply means adding more objects or more visual detail. In reality, complexity in 3D scenes rarely grows in a straight line. It compounds through interaction between systems.

That distinction becomes increasingly important as scenes evolve beyond isolated demos. The first object is usually easy. The ongoing challenge is keeping the scene predictable as more rendering decisions begin depending on one another.

Complexity appears through interaction, not object count

One of the biggest misconceptions in Three.js development is that complexity scales primarily through object count. Object count matters, but it is not the whole story.

In practice, complexity scales through interaction between systems. A single additional light source can change material appearance, shadow calculations, rendering cost, scene mood, and spatial readability. A camera adjustment can change composition, movement perception, interaction feel, and depth relationships. An animation update can change render timing, synchronization behavior, responsiveness, and motion continuity.

This interconnected behavior is what makes seemingly small scenes difficult to maintain. A change that looks isolated at code level may affect how the entire scene feels to the user.

A simplified dependency chain often looks like this:

Geometry
->
Material appearance
->
Lighting interaction
->
Shadow rendering
->
Performance impact
->
Perceived scene quality

The important detail is that changes rarely remain localized. A developer may adjust lighting to improve realism, only to discover that materials now appear overly reflective, shadows become visually noisy, scene contrast becomes inconsistent, or frame rate drops unexpectedly.

The original change was small. The resulting system impact is much larger.

This is one of the defining characteristics of Three.js applications: systems continuously influence one another. The difficult part is no longer understanding individual features in isolation. The difficult part is understanding how rendering systems behave collectively once the scene becomes more sophisticated.

That same coordination challenge is starting to shape how developers use AI tools in day-to-day engineering work. The value is not simply asking an assistant to generate code. It is learning how to structure implementation, inspect output, debug issues, and keep the workflow understandable as the project becomes more complex.

That is the focus of Learn Claude Code by Building Live, a live hands-on workshop built around practical AI-assisted development workflows. You’ll see how developers are using Claude Code across coding, debugging, reviewing AI-generated output, managing implementation workflows, and shipping software faster with structured practices.

Register now with a 40% early bird discount using code WEB40.

Lighting changes everything

Lighting is one of the clearest examples of hidden scene complexity.

In early Three.js experiments, lighting often feels secondary. Developers focus primarily on geometry because visible objects create immediate visual progress. But lighting determines how the entire scene is perceived.

Even simple lighting adjustments dramatically alter realism, atmosphere, depth perception, visual hierarchy, and readability. A scene with the same geometry can feel flat, dramatic, realistic, or confusing depending on how light is positioned and balanced.

For example, adding a directional light initially appears straightforward:

const light =
new THREE.DirectionalLight(
0xffffff,
1
);

light.position.set(5, 10, 7.5);

scene.add(light);

At first glance, this looks simple. The light has a color, an intensity, and a position. It is added to the scene, and the object becomes easier to read.

But lighting configuration quickly expands into broader considerations: shadow softness, contrast balance, reflection behavior, intensity calibration, color temperature, and rendering overhead. The complexity becomes more visible once multiple lights interact together.

Adding ambient light may improve visibility while simultaneously flattening scene depth. Increasing directional light intensity may improve realism while creating harsh contrast in unintended areas. Enabling shadows may improve depth but introduce performance cost.

This is why lighting rarely behaves like an isolated feature. It becomes part of the overall visual architecture of the scene. As projects mature, developers spend less time asking whether the light works and more time asking whether the lighting supports the experience consistently across the entire scene.

Materials introduce hidden rendering complexity

Materials often appear straightforward early in development. A developer selects a material type, applies a color or texture, and the object renders correctly. At prototype stage, that feels sufficient.

But materials are deeply connected to lighting behavior, reflections, transparency, render ordering, texture consistency, and performance characteristics. Material choices determine not only how an object looks, but how that object responds to the rest of the scene.

A simple material configuration might look like this:

const material =
new THREE.MeshPhysicalMaterial({
color: 0xffffff,
metalness: 0.8,
roughness: 0.2
});

The complexity is not immediately visible because the material appears correct in isolation. But as scenes evolve, materials begin interacting with multiple light sources, different environment maps, transparency layers, post-processing effects, and varied asset types.

This creates a coordination problem rather than a simple rendering problem. One object may appear overly reflective under certain lighting conditions. Another may absorb too much light. Texture resolution differences may become visually distracting once assets appear together inside the same scene.

These are not isolated rendering problems. They are scene consistency problems.

This is why material systems often become harder to manage over time than geometry itself. Geometry defines structure. Materials define how that structure is visually interpreted, and that interpretation changes continuously depending on the rest of the rendering environment.

Animation coordination becomes difficult quickly

Animation is another area where hidden complexity emerges gradually.

A single rotating object feels simple because the animation loop is easy to understand. The frame updates, the object rotates, and the renderer draws the updated scene:

function animate() {
requestAnimationFrame(animate);

cube.rotation.x += 0.01;
cube.rotation.y += 0.01;

renderer.render(scene, camera);
}

animate();

At prototype stage, this loop appears manageable because very little else is competing for synchronization. There is one object, one simple state change, and one render call.

But animation systems rarely remain isolated. As scenes evolve, animation begins interacting with camera movement, user interaction, lighting updates, physics systems, UI overlays, and asynchronous asset loading. This creates synchronization challenges that are far more difficult than the initial animation setup itself.

A simplified render relationship often looks like this:

User interaction
->
Animation updates
->
Scene state changes
->
Renderer updates frame
->
Camera reflects new state

The difficult part is no longer making objects move. The difficult part is ensuring movement remains coherent across the entire scene.

Animations that feel smooth individually may conflict once multiple systems update simultaneously. Timing inconsistencies become more noticeable. Interaction latency becomes more visible. Camera movement can make object animation feel too fast or too slow. UI overlays can make scene motion feel visually noisy.

This is one of the reasons polished 3D applications feel dramatically different from simple demos. The challenge is not merely creating animation. The challenge is coordinating animation behavior across the entire rendering system.

Scene organization matters more over time

Small Three.js scenes tolerate loose organization. Objects can exist directly inside the scene hierarchy without creating immediate problems. Early prototypes often remain understandable even with minimal structure.

As projects grow, however, organization becomes increasingly important. Grouping related objects improves transformation management, animation coordination, visibility control, scene readability, and maintainability.

A simple grouping structure might look like this:

const group = new THREE.Group();

group.add(mesh1);
group.add(mesh2);

scene.add(group);

Initially, this seems like a small architectural choice. Over time, decisions like this become foundational.

Without deliberate structure, animation logic becomes fragmented, object relationships become unclear, scene traversal grows more complicated, and interaction systems become difficult to manage.

The complexity of Three.js scenes often comes less from rendering itself and more from maintaining clarity as systems expand. This is where product-level thinking begins mattering more than individual rendering techniques.

Performance problems are usually architectural

Performance discussions around Three.js often focus heavily on rendering power. It is easy to assume that performance issues are mainly about the GPU, object count, or whether the browser can draw the scene quickly enough.

But many performance problems emerge from scene architecture rather than raw rendering capability. Examples include unnecessary object updates, excessive shadow calculations, uncontrolled geometry complexity, redundant render work, and poorly coordinated animation systems.

These issues accumulate gradually. A scene may perform well initially and degrade slowly as additional systems are introduced. Because the degradation is incremental, the underlying architectural cause is often harder to identify.

This is why optimization in Three.js is rarely about one dramatic fix. It usually involves improving coordination between systems: reducing unnecessary updates, simplifying lighting interactions, organizing scene hierarchy more effectively, and minimizing expensive rendering calculations.

The difficult part is not merely making a scene render. The difficult part is maintaining predictable performance as scene complexity grows.

Real complexity emerges through accumulation

One of the most important characteristics of Three.js development is that complexity compounds incrementally.

Rarely does a project become difficult because of one major rendering problem. Instead, one additional light is added, another animation loop appears, another material system is introduced, another interaction layer becomes necessary, and another responsive adjustment is required.

Each decision appears manageable independently. Together, they create an interconnected rendering system that requires significantly more coordination than the original prototype suggested.

This is why simple demos often feel deceptively complete. The early version demonstrates rendering capability. The mature version requires architectural discipline.

The difficult part is maintaining coherence

As Three.js scenes evolve, developers increasingly spend time maintaining coherence across rendering behavior, material consistency, animation timing, interaction responsiveness, scene organization, and performance stability.

This is where the nature of development changes.

The challenge is no longer:

Can we render this object?

The challenge becomes:

Can we keep the entire scene predictable, performant, and visually coherent as the system grows?

That is a fundamentally different kind of problem.

It requires structure, restraint, coordination, iterative refinement, and long-term thinking. These are architectural concerns rather than rendering concerns.

Key takeaways

• Simple Three.js scenes become complex through interaction between systems, not just object count.

• Lighting, materials, camera behavior, animation, and performance continuously influence one another.

• Demos can appear complete before the underlying scene structure is ready for real application growth.

• Performance issues often emerge from scene organization and repeated updates rather than rendering alone.

• The long-term challenge is maintaining visual and structural coherence as the scene evolves.

Conclusion

Three.js scenes often appear simple during the early stages of development. A few objects, lights, and animations can quickly create impressive visual output.

But the hidden complexity of 3D applications emerges through interaction between systems.

Lighting affects materials. Animations affect rendering behavior. Responsiveness changes composition. Scene hierarchy affects maintainability. Performance depends on coordination across all of them.

The difficult part is not rendering the first object.

The difficult part is maintaining coherence as rendering, interaction, lighting, animation, and performance begin influencing one another simultaneously.

That is where simple scenes stop behaving like demos and start behaving like real applications.

This Week in the News

• 🥖 Bun’s million-line leap from Zig to Rust: Bun just made one of the boldest runtime moves we’ve seen in a while: a 1 million line PR that ports its codebase from Zig to Rust, only days after the branch was described as “experimental.” The reason is practical enough. Bun’s team has been chasing memory leaks and unpredictable crashes, and Rust gives them stronger language-level guardrails for exactly those problems. Still, swapping the foundation of a project this fast is bound to make developers nervous.

• 🧨 TanStack’s npm compromise shows why fresh installs need a safety buffer: A malicious npm publish hit 42 @tanstack/* packages this week, with 84 compromised versions live for a short window before being caught. The incident was contained quickly, but it still exposed a real risk for teams running fresh installs in local or CI environments. The practical move is to add friction around brand-new package releases, using safeguards like npm’s min-release-age, pnpm’s minimumReleaseAge, and GitHub Actions checks with tools such as zizmor.

• 🛡️Next.js patches 13 vulnerabilities that teams should not leave to the firewall: Next.js shipped a coordinated security release covering 13 vulnerabilities across denial of service, middleware and proxy bypass, SSRF, cache poisoning, and XSS. Several issues cannot be fully mitigated by cloud firewalls, so the recommendation is straightforward: update to 15.5.18 or 16.2.6. There is also a related React Server Functions denial-of-service issue fixed in React RSC packages 19.2.6.

• 🏗️ Anthropic’s Colossus deal puts AI infrastructure back in the spotlight: Anthropic’s latest compute expansion shows how much frontier AI now depends on access to massive infrastructure. SpaceX and xAI are making Colossus 1 available to Anthropic, giving Claude more capacity as demand grows. The bigger signal is that model competition is no longer only about architecture or benchmarks. It is also about who can secure enough compute, power, and data center capacity to keep products reliable at scale.

• 🤖 AgentField turns multiple coding agents into one TypeScript workflow: AgentField is positioning itself as a TypeScript harness for composing Claude Code, Codex, Gemini, and other coding agents into repeatable workflows. The interesting shift is from prompting one assistant at a time to coordinating agents with recipes, constraints, and reusable patterns. For teams experimenting with agentic development, this points toward a more structured way to test what coding agents can actually do together.

Beyond the Headlines

• ⚖️ Tokenmaxxing asks whether AI is increasing progress or just output: This piece pushes back on the idea that more AI-generated work automatically means better engineering. Faster coding can help teams explore more ideas, but it can also create more noise, more unfinished features, and more coordination overhead. The useful question is not “how much can we generate?” but “what is worth keeping?”

• 🧬 React2Shell shows how curiosity can become an ecosystem-level security story: This write-up traces the story behind React2Shell, an unauthenticated RCE in React Server Components. The value is not only in the vulnerability itself, but in how the discovery unfolded: curiosity, protocol digging, and a fast-moving disclosure process. It is a useful read for anyone working near modern React infrastructure.

• 🔍 AI is putting pressure on old vulnerability disclosure norms: Jeff Kaufman looks at how AI changes the balance between quiet security fixes and coordinated disclosure. When AI can scan commits and infer security impact faster, “silent” fixes become easier to spot, and long embargoes become harder to manage. The result is a security culture clash that maintainers may not be able to ignore.

• 🧩 Library patterns keep shaping what the web platform becomes: This piece looks at how library patterns have influenced the web platform over time. The takeaway is simple: when developers repeatedly solve the same problem in userland, it often points to a missing browser primitive. Today’s popular library workaround can become tomorrow’s platform feature.

• ⚛️ React Server Components in five minutes: This short deep dive is a useful companion to the React2Shell discussion because it focuses on the underlying React Server Components model. For developers who want a quick refresher, it helps connect the security conversation back to the architecture: what runs on the server, what reaches the client, and why those boundaries matter so much in modern React apps.

Tool of the Week

🐀 Ratty makes the terminal weird, visual, and fun again

Ratty is a terminal emulator with inline 3D graphics and a spinning rat cursor. It is playful, strange, and clearly built with a sense of humor, but that is what makes it worth a look. Developer tools do not always need to be purely utilitarian. Sometimes the experiment itself is the point.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.

Mark is also a bestselling author of programming books across .NET, C#, Python, and modern web development,

Mark brings a practical, developer-first lens to building strong technical foundations. Today’s piece is drawn from his book Web Development with an AI Sidekick.

AI has changed the texture of web development work. A few years ago, most of us bounced between docs, Stack Overflow, GitHub issues, and half-finished notes in our own repos. Now, many developers open a chat window first. We ask for an explanation, a starter function, a refactor, a regex fix, or a quick way to debug a failing script. That shift is real, and it is already shaping how people learn and build.

Still, the real advantage does not come from generating code faster. It comes from using AI without giving away the thinking that makes you a stronger developer.

That matters most at the intermediate stage. Once you are past the basics, progress stops being about syntax recall alone. The actual challenge is understanding behavior, data flow, failure modes, and the trade-offs that sit behind everyday implementation choices. AI can support that process beautifully. It can also make it easier to skip it.

The difference comes down to one thing: your mental model.

Before we get into it, here’s a sneak peek of this week’s highlights:

• 🚀 Node.js 26 is here with Temporal by default, V8 14.6, and new JavaScript capabilities.

• 🌀 Remix 3 beta feels like a full reset, moving toward a web standards-first framework without React at the center.

• 🧭 VS Code 1.119 sharpens agent workflows with smoother browser access, telemetry, and sandbox improvements.

• 🌐 Mozilla makes the case for trustworthy JavaScript and stronger guarantees around delivered browser code.

• ⏱️ Time to Yield revisits frontend responsiveness and why performance is also about keeping the interface alive.

• ✨ Anime.js keeps web animation approachable with timelines, SVG animation, scroll effects, and draggable interactions.

JavaScript still lives or dies on behavior

In frontend work, JavaScript remains the place where user behavior becomes actual application behavior. A click updates a count. A form input changes local state. A toggle shows hidden content. A validation rule decides whether something can be submitted. These are ordinary interactions, but they expose the central challenge of frontend development: the browser is always reacting to changing state.

That is why JavaScript becomes harder long before it becomes “advanced.” The difficulty usually is not the syntax. It is the chain of cause and effect. One event triggers a function. That function updates a variable. The UI reads that value and renders it. Another function depends on that same value later. At that point, you are no longer writing isolated lines of code. You are managing behavior.

const button = document.querySelector(’#save’);
const status = document.querySelector(’#status’);

button.addEventListener(’click’, async () => {
status.textContent = ‘Saving...’;

try {
await saveDraft();
status.textContent = ‘Saved successfully’;
} catch (error) {
status.textContent = ‘Something went wrong’;
console.error(error);
}
});

This is a small example, but it shows the real shape of frontend work. The question is not just “does it run?” The question is “what should the user see while something is happening, and what should happen when it fails?”

That is also where AI can be genuinely useful. I find it most helpful when it is asked to explain behavior, not just produce output. If you ask it, “Why might this click handler fail silently?” or “What edge cases should I think about here?” you get much better value than you do from “write this feature for me.”

The browser still rewards developers who can reason clearly about state, events, and side effects. AI helps, but it does not remove that requirement.

Debugging is still a first-class skill

One quiet risk with AI-generated code is that it can make clean-looking code feel trustworthy before it has earned that trust.

A function can look polished and still rely on DOM elements that do not exist. A promise can be written cleanly and still swallow an error. A generated solution can solve the visible symptom while leaving the original logic problem untouched. That is why debugging remains one of the most important skills in modern web work.

The console is still your friend. So are breakpoints, network inspection, and reading stack traces without panic. AI can help interpret an error, but the developer still needs to inspect the real runtime conditions.

const form = document.querySelector(’#signup-form’);

console.log(’Form found?’, !!form);

form?.addEventListener(’submit’, (event) => {
event.preventDefault();
console.log(’Form submitted’);
});

This snippet is simple, but it reflects a useful habit: check your assumptions in the environment where the code actually runs.

That habit matters more in AI-assisted workflows. If you paste an error into a chatbot before you inspect the actual state of the page, you risk outsourcing the wrong question. The better sequence is this: reproduce the issue, inspect the DOM or runtime values, form a hypothesis, then ask AI to help test or refine that hypothesis.

That turns AI into a debugging partner rather than a guess machine.

TypeScript makes fuzzy assumptions visible

JavaScript gives you freedom. TypeScript pushes back when that freedom becomes vague.

That is why TypeScript matters even for developers who already “know JavaScript.” Its biggest benefit is not prestige or complexity. It is visibility. It reveals where your assumptions are too loose.

If a user may not have a profile image, the code should say so. If a function returns either success data or an error object, the code should say so. If a property can only be one of three allowed strings, the code should say so.

That sounds obvious, but teams often carry these assumptions informally. AI-generated code tends to make that worse because it often fills in the blanks with something plausible rather than something verified.

type SurveyStatus = ‘draft’ | ‘published’ | ‘closed’;

interface Survey {
id: number;
title: string;
status: SurveyStatus;
responseCount?: number;
}

function getStatusLabel(survey: Survey): string {
if (survey.status === ‘draft’) return ‘Work in progress’;
if (survey.status === ‘published’) return ‘Live now’;
return ‘No longer accepting responses’;
}

This is not flashy code, but it is valuable code. It makes the shape of the data easier to understand at a glance. It also gives your editor a chance to protect you from sloppy assumptions.

This is where AI becomes much more effective, too. When you prompt with clear data shapes, expected states, and explicit constraints, the quality of the generated response improves immediately. Good prompts in development often look a lot like good system design. They define what is allowed, what is optional, and what should happen when something is missing.

Developers sometimes treat TypeScript as overhead because the application seems small. The problem is that applications rarely stay small in the ways that matter. They grow in decisions, edge cases, and invisible dependencies. TypeScript helps bring those decisions into the open.

Backend work rewards structure earlier than people expect

On the backend, the same pattern appears in a different form. It is easy to write a Python script that works once. It is much harder to build backend logic that stays understandable after a few rounds of changes, debugging, and feature growth.

That is why the backend conversation should not just be about language choice or framework speed. It should be about structure. Small functions, sensible modules, meaningful variable names, clear error handling, and isolated responsibilities all matter much earlier than most people expect.

def calculate_completion_rate(total_responses, completed_responses):
if total_responses == 0:
return 0

return round((completed_responses / total_responses) * 100, 2)

A tiny function like this is not interesting because it is clever. It is useful because it is readable, testable, and easy to reuse. That is often the better way to judge backend code quality. Not “How compact is it?” but “Can I understand it six weeks later?”

AI can help a lot here. It can suggest cleaner names, extract a helper function, explain a traceback, or show a better way to handle a repeated block of logic. Still, the best outcomes come when you already know what kind of structure you want.

If you ask AI to “write backend code for analytics,” you may get something that works. If you ask it to “separate data access, business logic, and formatting concerns,” you are much more likely to get something maintainable. That difference matters.

Good AI usage looks more like collaboration than delegation

There is a lot of talk about prompt engineering, but for most working developers, the real skill is much simpler: knowing how to ask better technical questions.

Strong AI-assisted development usually includes some version of the following habits:

• asking for an explanation before asking for a solution

• requesting alternatives and trade-offs, not just one answer

• giving the model the data shape, edge cases, and constraints up front

• reviewing generated code line by line before accepting it

• testing in the real environment, not just trusting a neat-looking response

Those habits keep you in the driver’s seat.

Bad prompt:
“Write a form validation function.“

Better prompt:
“Write a TypeScript function that validates a survey form.
Fields: title (required, min 5 chars), email (optional, valid format if present),
questions (must contain at least 1 item).
Return an object with field-specific error messages.“

The real pattern is bigger than any one language

What I find most interesting is that the same deeper ideas keep showing up across the stack.

In JavaScript, you are reasoning about user interaction and state changes. In TypeScript, you are making assumptions explicit so those changes stay manageable. In Python, you are organizing logic so that behavior can scale without becoming confusing. Different syntax, same underlying discipline.

That is why AI works best for developers who are trying to strengthen their mental model, not bypass it.

A developer with a clear mental model asks better questions:

• What state is changing here?

• What data shape does this function expect?

• What happens when the input is missing or invalid?

• Where should this responsibility live?

• How should the system fail?

• Is this solution easier to maintain than the last one?

Those questions improve your code even before AI answers them. Then AI becomes useful in the right way. It helps you refine, test, explore, and debug. It stops being a code vending machine and starts acting more like a second pair of eyes.

Takeaways

AI is now part of the everyday web development toolkit, and that is not changing. The developers who benefit most will not be the ones who hand over every task blindly. They will be the ones who use AI to sharpen their understanding of the stack.

JavaScript still demands a clear grasp of browser behavior. TypeScript still rewards developers who make assumptions explicit. Python still works best when logic is structured early and cleanly. Across all three, the strongest habit is the same: treat generated output as something to interrogate, not something to trust by default.

That is the mindset worth building.

AI can speed up the path to a solution. Your mental model determines whether the solution actually holds up.

If this way of thinking about AI-assisted development resonates with you, Web Dev with an AI Sidekick builds on the same idea in a more structured, practical way. You can pre-order the book on Amazon here: Web Dev with an AI Sidekick

Join Anna J McDougall, Field CTO at HashiCorp / IBM, for a live workshop on how engineering careers are evolving in the AI era.

📅 May 30 | Live Online Workshop

Register Now

This Week in the News

• 🚀 Node.js 26 lands as the new Current release: Node.js 26 is here, with the Temporal API enabled by default, V8 14.6, and Undici 8. Developers also get new JavaScript capabilities such as Map.prototype.getOrInsert() and Iterator.concat(). This is the cutting-edge Current release until October, when Node.js 26 is expected to move to LTS. It is a good time to test compatibility, explore the runtime changes, and see what might affect production workflows later this year.

• 🌀 Remix 3 beta preview takes a sharper turn: Remix has had a long journey: it was created by the team behind React Router, positioned as an alternative to Next.js, acquired by Shopify, and later folded into React Router v7. Now Remix 3 is stepping out in a new direction: a full-stack, web standards-first framework with its own UI component model and no React at the center. It feels less like a version bump and more like a reset.

• 🧪A Bun experiment turns into a bigger debate: Jarred Sumner added a Zig to Rust porting guide to the Bun repo, and Hacker News quickly turned it into a much larger conversation about Bun’s future. The speculation got intense enough that Jarred stepped in and said the whole thread was an overreaction. It is a small reminder of how closely developers watch fast-moving tools. Even an experiment can look like a strategy shift when the project has this much attention.

• 🧭 VS Code 1.119 sharpens agent workflows: VS Code 1.119 focuses on smoother agent interactions, better observability, and fewer workflow interruptions. Agents can now request access to shared browser tabs, Copilot Chat sessions can emit OpenTelemetry traces, and sandboxed agents get more practical network and temporary-file permissions. It is another step toward making AI coding agents feel less separate from the editor.

Beyond the Headlines

• 🔐 Security through obscurity deserves a better conversation: This piece challenges the usual dismissal of “security through obscurity.” The argument is not that obscurity should replace strong security, but that it can still be useful as one extra layer. It is a thoughtful read for anyone who has seen good security advice turn into rigid slogans.

• 🥯 A developer worries about Bun’s future: This post looks at Bun with both admiration and concern. The runtime is fast, ambitious, and widely loved, but its future now carries bigger questions around ownership, priorities, and long-term stewardship. The piece is a developer asking what happens when a tool people rely on becomes part of a much larger company story.

• 🌐 Mozilla makes the case for trustworthy JavaScript: Mozilla explores how web apps can make their delivered JavaScript more trustworthy. The core concern is simple: users need a way to know that the code running in the browser is the code developers intended to ship. This matters most for high-trust apps, especially where privacy and encryption are involved. The open web needs stronger ways to make invisible tampering harder to hide.

• 🎥 A useful watch for your developer queue: I would keep this as a short watchlist item unless you want to share the title or main theme. Without that, the safest version is simple and curiosity-led. This video is worth saving for a slower watch, especially if you like technical talks that connect engineering decisions with the way developers actually build, debug, and maintain software.

• ⏱️Time to Yield revisits frontend responsiveness: This piece looks at yielding and responsiveness from a practical frontend angle. It is less about chasing benchmark wins and more about how JavaScript work affects the user’s experience. That framing is useful because performance is not only about speed. It is also about when work happens, how much room the browser gets, and whether the interface still feels alive under pressure.

Practical AI for Working Developers

AI is moving fast, and for a lot of developers, keeping up still feels like learning through trial and error.

BuildWithAI is Packt’s newsletter for engineers who want to move beyond AI headlines and start using it in real projects.

Backed by Packt’s 7,000+ tech books, courses, and expert resources across 1,000+ technologies, each issue brings you practical workflows, carefully chosen resources, and implementation guidance you can actually apply. Subscribe here.

Tool of the Week

Anime.js keeps web animation approachable ✨

Anime.js gives developers a polished way to build expressive motion on the web, from timelines and SVG animation to scroll-triggered effects and draggable interactions. It is useful when animation needs to feel intentional rather than decorative. The API stays approachable, but there is enough depth for teams building more crafted, interactive interfaces.

Crashcat makes physics demos surprisingly fun 🐱

Crashcat is a JavaScript 3D rigid body physics library for games, simulations, and interactive web experiences. It also has the kind of homepage you remember: a cat in a convertible driving through endless obstacles.

That playful first impression works. The examples make the library feel inviting before the technical details take over.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

Catch the latest HubSpot Developer Platform updates in Spring Spotlight

Spring Spotlight 2026 is live and we’ve rounded up the top updates for developers. See what’s new for the HubSpot Developer Platform!

Ship faster with AI coding tools like Cursor, Claude Code, and Codex. Build MCP-powered AI connectors, run serverless functions with support for UI extensions, and use date-based versioning to streamline roadmap planning.

Explore Now

Welcome to this week’s issue of WebDevPro!

Today’s piece comes from Alexandre Zajac, an engineer from Prime Video who’s been thinking deeply about how AI coding workflows actually behave in the real world.

Alex doesn’t just experiment at the surface level; he digs into the friction points, the failure modes, and the patterns that emerge when you push agents beyond toy problems.

He built this PDF starter kit to help you go through it!

In this article, he walks through a practical system for making agentic coding reliable, drawing from firsthand experience and real constraints. It’s thoughtful, grounded, and immediately useful if you’ve ever felt your AI sessions spiral after a few dozen turns.

Before we get into it, here’s a sneak peek of this week’s highlights:

• 🧠 A new contender just entered the coding model race

• ⚙️ Cursor just turned its agents into an API

• ⚛️ React is still trying to automate performance

• 🟢 Node 26 hit a delay, but Temporal is still close

• 🧠 Where the goblins in ChatGPT actually came from

• 🧩 Coding is shifting from prompts to orchestration

  ---

👋 Hi! It’s Alex!

Let’s imagine this scene. You open a new chat. You describe the feature.
For twenty minutes, the AI is cooking.
Good code, too.

Around turn 30, it starts fixing a bug it introduced three turns ago.
It imports a module you deleted. It references a file path you renamed ten messages back.

You’re not building anymore. You’re managing.

Feeding corrections back in, watching the agent regenerate the same broken pattern with different variable names.

This is the death loop, and it’s not a prompt quality problem.
Session length is the variable that matters.

I created a simple system to ship simple changes with agents (almost) autonomously, and in this article, I want to show the why and how I built it.

Context erosion

The Anthropic Claude Code docs say it directly: a single debugging session can generate tens of thousands of tokens, and when the context window fills up, Claude starts forgetting earlier instructions and making more mistakes.

A 10-turn session is fine.
A 50-turn session drifts.
At 80 turns, you’re spending more time correcting than building, and at that point, you might as well have written the code yourself.

Birgitta Böckeler, writing in the Martin Fowler engineering series, said it after months of daily agentic coding: the longer a session gets, the more hit-and-miss it becomes, regardless of the rigor in prompting.

Assumption stacking

Agents make assumptions about your codebase.
Most are correct.

When one is wrong and goes unchallenged, the agent builds on it. Then you build on the agent’s code. Three levels in, the wrong assumption is load-bearing.

Documented example from the same Martin Fowler series: an agent diagnosed a Docker build failure as an architecture mismatch and changed the Docker settings. The actual cause was node_modules built for the wrong platform. Classic error. Any developer who’s been burned by it once would catch it in 30 seconds. Without that catch, the agent would have spent hours deepening a wrong diagnosis into increasingly creative fixes.

Agents are confidently wrong with no built-in correction mechanism.

Filesystem collisions

Two agents, one working directory:

• agent-1:

git add . && git commit -m “fix auth middleware”

• agent-2:

git add . && git commit -m “refactor API layer”

# agent-2 just committed agent-1’s half-finished auth changes

Every agent sees every other agent’s uncommitted changes.
Files get overwritten mid-edit.
One agent’s npm install blows away another’s node_modules.

Commits become incoherent.

Open two Cursor tabs on the same repo and give it 20 minutes. Productive at first. Then a mess that takes longer to untangle than doing the work sequentially.

So how do we make this consistently okay?

Stage 1: The PRD

A PRD is not a 47-page corporate artifact. It’s a short document you write before opening your coding tool. Its job: prevent assumption stacking before the agent gets a chance to start.

I always use these for medium-to-large features.

It’s similar to the Harper Reed workflow published in February 2025.

It got traction because it was concretely different from how most people worked at the time. His first move is a conversational spec session where an LLM asks him one question at a time until the idea is fully elaborated.

The prompt:

“Ask me one question at a time so we can develop a thorough,

step-by-step spec for this idea. Each question should build

on my previous answers, and our end goal is to have a detailed

specification I can hand off to a developer. Let’s do this

iteratively and dig into every relevant detail. Remember,

only one question at a time.”

Here’s the idea: [IDEA]

When the questions run dry:

“Now that we’ve wrapped up the brainstorming process, can you

compile our findings into a comprehensive, developer-ready

specification? Include all relevant requirements, architecture

choices, data handling details, error handling strategies,

and a testing plan so a developer can immediately begin

implementation.”

Output goes to spec.md. The whole thing takes 15 minutes.

The Doozy founders shipped a 300k-line Next.js monorepo with 3 to 6 parallel agents at any given time. They do it differently. They built a /discussion command that runs before any code is written. Subagents explore the codebase and look up dependencies. The command produces no edits, only a written summary in .context/context.md. Other agents reference that file.

What goes in the spec

# spec.md

## Problem

What you’re building and why, in one sentence.

## Constraints

What the agent should NOT touch.

What patterns to follow.

## Files to read

src/auth/middleware.ts

src/routes/users.ts

prisma/schema.prisma

## Definition of done

npm run typecheck && npm test passes with no new failures.

150 to 300 words. The format matters less than writing it before you start prompting.

One test: if you can’t describe what the feature should not do, keep writing.

Where it lives: spec.md in the repo root, a context section in CLAUDE.md, or .context/context.md. Pick whatever your tool loads by default.

Watch out for CLAUDE.md files that balloon. The Claude Code docs are explicit about this: bloated CLAUDE.md files cause Claude to ignore your actual instructions. Treat it like code. Prune it. If you added a rule and Claude’s behavior didn’t change, the rule is noise. Delete it.

Stage 2: The task planner

The task planner converts a spec into a sequenced list of bounded tasks. Harper Reed uses a reasoning model for this step, and I do too. Not for code, just for decomposition.

A possible prompt:

Draft a detailed, step-by-step blueprint for building this project.

Then break it down into small, iterative chunks that build on each

other. Go another round to break it into small steps. Review and

make sure the steps are small enough to implement safely, but big

enough to move the project forward.

Make sure each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn’t integrated into a previous step.

[SPEC]

Output goes to prompt_plan.md. Then he asks for a todo.md checklist the execution agent can check off. That’s how state persists across sessions without re-reading the full conversation history.

Anthropic describes this as the orchestrator-workers pattern: a central LLM breaks down tasks, delegates them to worker LLMs, and synthesizes results. The reasoning is that you can’t always predict the subtasks, especially in code, where the number of files and the nature of changes depend on the task.

What “agent-sized” means

A task is agent-sized if it fits in one context window, produces a green lint/typecheck, and has a binary done/not-done signal.

These will send your agent spiraling:

❌ “Refactor the authentication system”

❌ “Add tests”

❌ “Improve performance”

These work:

✅ “Add a useAuth hook to src/hooks/auth.ts that wraps the

existing authService and exposes login, logout, and

isAuthenticated. Update src/components/LoginButton.tsx

to use it. Done when: npm run typecheck passes.”

✅ “Add a POST /api/users/:id/preferences endpoint to

src/routes/users.ts that validates the body against

UserPreferencesSchema and writes to user_preferences.

Done when: the new route test passes.”

Specific file. Specific interface. Specific check.

The Pane team scores every plan on a 1-10 confidence scale for one-pass implementation success. Below 8, iterate. Their rules: no aspirations, only instructions. No open questions (if something is unresolved, stop and research first). And if a plan is too big for one session, split it. Oversized plans are where the death loop starts.

Stage 3: Parallel agents

Here are the 3 concepts I use the most to make parallel agents work.

Once you have a dependency-ordered task list, tasks that don’t share files can run at the same time. The thing that used to block this was filesystem collisions. The fix has been sitting in git since 2015.

Git worktrees

One command. Sub-second. The new directory is a fully independent working tree on its own branch, sharing the same .git object store. No re-cloning. Disk cost is just for your working files.

git worktree add .worktrees/feature-auth -b session/feature-auth

Each agent gets a clean branch, zero visibility into other agents’ uncommitted changes, and full ability to run tests independently.

When done:

git worktree remove --force .worktrees/feature-auth

The branch stays if there are commits to review. Otherwise, it’s gone.

This primitive from 2015 that nobody cared about until this year now underpins several independent tools:

• amux runs up to 30 Claude Code agents in parallel. Uses SQLite compare-and-swap for atomic task claiming. No Redis. No Kubernetes. Just a WHERE clause and SQLite’s write lock.

• Emdash (YC W26) is an open-source desktop app supporting 20+ CLI providers, including Claude Code, Codex, and Gemini CLI, with direct integration into Linear, GitHub, and Jira, plus SSH to remote machines.

• Pane is open-source, from the Doozy founders. Same team behind the 300k-line monorepo. Cross-platform, agent-agnostic, keyboard-first.

All of these solutions are great, but in reality, to get started, none of them are required.
A task file and a terminal per worktree gets it done.

Scoping agents

Every agent session starts with the task description from the plan, the specific files listed in the task, and the relevant section of the spec.

# Task: Add useAuth hook

Files to read:

- src/services/authService.ts (existing service to wrap)

- src/hooks/ (existing hook patterns to follow)

- src/components/LoginButton.tsx (file to update)

Constraints: Do not modify authService.ts.

Done: npm run typecheck passes, LoginButton uses useAuth.

The agent can’t drift into adjacent work because adjacent work isn’t in its context. It either completes the task or fails clearly.

Ten 20-turn sessions instead of one 200-turn session.

Integration checks

TypeScript strict mode, npm run typecheck, and lint are your coordination layer across parallel agents. An agent’s work isn’t done until the checks pass. This prevents a type error in one worktree from silently propagating when branches merge. This scales across languages.

Try to enforce this per task: implement, typecheck, lint, format, and fix all issues before proceeding. After all tasks finish, a reviewer subagent reruns everything and verifies that the plan was completed.

Human review stays in the loop for architectural decisions, ambiguous acceptance criteria, and code that’s syntactically valid but semantically wrong. Automated checks catch everything describable as a rule. They don’t catch everything.

What this still doesn’t fix

Agents still hallucinate library APIs. They’ll write syntactically correct code against an API that changed in the last major version. The planning stage reduces this by including research tasks with URLs, but it doesn’t eliminate it. Verify unfamiliar library usage against docs before shipping.

The spec quality ceiling is your knowledge. If you don’t understand your codebase well enough to write a clear spec, the agent won’t either. The planning phase surfaces this. If you can’t finish the plan without open questions, you need to learn more before you start.

Merge conflicts still happen when two tasks share a file the plan didn’t account for. Worktrees stop filesystem collisions. They don’t do design work.

The tooling layer is moving fast. Git worktrees are stable. The orchestration tools built on top of them aren’t. Build your workflow around git worktree add, not the wrapper tool.

Context pollution goes both ways. Too little context and the agent hallucinates your conventions. Too much, and the real rules get buried. The same principle applies to task files: dense, explicit, and short.

Entropy compounds. Incomplete refactors, mixed conventions, dead code. All of it degrades agent performance on the next feature because the agent has to reason about a messier codebase. This workflow doesn’t fix that.

Where to start this week

Don’t adopt all three stages at once.

Start with Stage 2. Before your next AI coding session, spend 10 minutes writing a task plan. Three things:

1. Which files does this touch (name them)

2. What it should NOT do (scope the blast radius)

3. The done signal (what command passes when it’s complete?)

No new tools. No worktrees yet. Write it down first.

Once that’s a habit, add Stage 1. The spec forces you to resolve assumptions before the agent makes them for you. This + a 15-minute planning session will save you 2+ hours of correction.

For parallel execution: git worktree add before you open a second tab.
One command, isolated branch, no collisions.

This Week in the News

• 🧠 A new contender just entered the coding model race: Jason Warner, GitHub’s former CTO’s startup, Poolside has released a new set of agentic coding models built specifically for software engineering workflows. This is a focused bet on where development is heading, with models designed for control, performance, and real-world coding tasks rather than general-purpose use.

• ⚙️ Cursor just turned its agents into an API: Cursor’s new TypeScript SDK lets you invoke its coding agents from CI pipelines, backend services, or even your own product. This moves agents out of the editor and into the system itself, where they can run tasks, automate workflows, and become part of how software gets built.

• ⚛️ React is still trying to automate performance: A year into the React Compiler experiment, the direction is becoming clearer. The goal is to shift performance optimization away from developers by letting the compiler handle memoization and rendering decisions, reducing the need for manual tuning in complex applications.

• 🟢 Node 26 hit a delay, but Temporal is still close: Node 26.0 was expected to land with the Temporal API enabled by default, but a macOS-related problem led to a last-minute delay. A fix is already in progress and a new release candidate is available, keeping Temporal on track to become part of the standard Node experience.

• 🧠 Where the goblins in ChatGPT actually came from: OpenAI dug into a strange behavior where its models kept referencing goblins and other creatures in unrelated contexts. The cause wasn’t a bug in the usual sense. It came from subtle training incentives, especially around personality tuning, where certain kinds of metaphors were rewarded more than expected and then spread across the model. It’s a small, almost funny example, but it points to something deeper. Model behavior is shaped by many tiny signals, and those signals don’t always stay contained.

  ---

Beyond the Headlines

• 🧩 Coding is shifting from prompts to orchestration: This piece makes it clear that the real shift is not better prompts, but better coordination. Codex is evolving into a system that orchestrates multiple steps, tools, and agents to complete work. The focus is no longer on generating code, but on managing how that code gets produced.

• ⚠️ When output looks right but meaning drifts: A small example shows how generated output can subtly drift from the original intent while still looking correct. Nothing is obviously broken, which is exactly why it gets through. This is the kind of failure that does not show up in syntax or tests, but in meaning.

• 🧠 Work that looks complete but lacks depth: This piece explores how modern tools can produce outputs that resemble real knowledge work without the depth behind them. The results look finished, but the reasoning is often shallow. That gap becomes clear the moment judgment is required.

• 🔐 SVGs are still an easy way to get security wrong: SVGs look harmless, but they can carry scripts and unexpected behavior if not handled carefully. This write-up shows how common sanitization approaches fail and why this issue keeps slipping into production systems.

• ⚛️ Most React accessibility issues are small and avoidable: Accessibility problems in React apps rarely come from complex logic. They come from small gaps like missing labels, broken semantics, and poor keyboard support. These are easy to miss and just as easy to fix once you know where to look.

  ---

Tool of the Week

🎬 Scroll-driven animations that finally feel natural

Most scroll animations feel disconnected because they rely on timelines instead of user input. This guide shows how to tie motion directly to scroll position, which makes interactions smoother and easier to reason about. It’s a small shift in approach that fixes a surprisingly common UI problem.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.

Spring Spotlight 2026 is live, and we’ve rounded up the top updates for developers. See what’s new for the HubSpot Developer Platform! Ship faster with AI coding tools like Cursor, Claude Code, and Codex.

Build MCP-powered AI connectors, run serverless functions with support for UI extensions, and use date-based versioning to streamline roadmap planning.

Explore Now

Welcome to this week’s issue of WebDevPro!

Node.js is often chosen for its ability to handle concurrent workloads efficiently. Its event-driven, non-blocking architecture allows applications to process multiple operations without waiting for each one to complete. This model is particularly effective in I/O-heavy systems where responsiveness matters more than sequential execution.

Because of this, there is a widespread assumption that Node.js applications will perform well under load by default. In practice, that assumption depends on one critical condition: the application must remain non-blocking. Once blocking behavior is introduced, the system begins to behave very differently.

Blocking code does not always cause immediate failures. In development environments, where concurrency is limited, the system may appear stable. Requests complete, responses are returned, and nothing seems obviously wrong. This creates a false sense of confidence in how the application will behave in production.

Under real-world conditions, however, multiple operations occur simultaneously, and the event loop becomes a shared dependency across all of them. At that point, the cost of blocking becomes visible. Delays accumulate, responsiveness drops, and the system begins to struggle under load. The issue is not simply that blocking code exists, but how it interacts with the event loop and how that interaction scales.

Before we get into it, here’s this week at a glance:

• ⚛️ TanStack Start adds experimental React Server Components support

• 🤖 Claude introduces “routines” for repeatable workflows

• 🧩 GitHub introduces stacked PRs in private preview

• 🎨 Why AI still struggles with frontend development

• 🧹 Mastering ESLint rules for better code quality

• 🎤 Inside npmx, a new way to explore the npm ecosystem

What blocking means in practice

In Node.js, all JavaScript execution happens on a single thread, coordinated by the event loop. The event loop continuously processes tasks by retrieving them from a queue, executing them, and delegating work when possible so that execution can continue without interruption. This model works efficiently because it assumes that tasks will be short-lived and non-blocking.

Blocking code violates this assumption. When a blocking operation is executed, the event loop cannot proceed to the next task until the current one completes. This does not simply delay a single operation. It prevents all other pending tasks from executing during that time, effectively pausing the system’s ability to make progress.

The impact is broader than it first appears. Callbacks that are ready to run remain in the queue. Timers do not fire at expected intervals. Incoming requests must wait before they can even begin execution. What appears to be a local delay becomes a system-wide bottleneck.

This shared delay is what makes blocking code particularly problematic in Node.js. In systems with multiple threads, delays can be absorbed or distributed. In Node.js, the delay is centralized. A single blocking operation affects everything else that depends on the event loop.

Why synchronous APIs are risky in Node.js

Synchronous APIs are often attractive because they simplify reasoning about code. Execution flows in a straight line, making it easier to follow and debug. This simplicity can be beneficial in scripts or isolated tasks where concurrency is not a concern.

In an event-driven system like Node.js, however, synchronous APIs introduce a significant limitation. Because they execute on the main thread, they block the event loop until they complete. During this time, no other operations can be processed, regardless of how unrelated they may be.

This creates a disconnect between how the code appears and how it behaves under load. The code may look efficient and predictable, but its execution forces all operations into a sequential pattern. Instead of handling multiple tasks concurrently, the system processes them one at a time.

The result is reduced flexibility in how work is handled. As more operations depend on the event loop, the impact of synchronous APIs becomes more pronounced. What begins as a simple design choice can evolve into a system-wide constraint.

CPU-intensive work and hidden blocking

Blocking behavior is not limited to I/O operations. CPU-intensive tasks can have an even greater impact, particularly when executed synchronously. These operations consume the main thread for their duration, preventing the event loop from processing other tasks.

The book illustrates this with a cryptographic key generation example, where a synchronous function is executed repeatedly. Each iteration runs on the main thread, and the cumulative effect is a prolonged period during which the event loop is unavailable.

performance.mark(”start-sync”);
for (let i = 0; i < 10000; i++) {
generateKeyPairSync(”rsa”, {
modulusLength: 1024,
});
}
performance.mark(”end-sync”);
performance.measure(”generateKeyPairSync”, “start-sync”, “end-sync”);

In this scenario, the cost is not just the execution time of a single operation, but the accumulation of blocking across many iterations. The event loop remains occupied for the entire duration, preventing any other work from progressing.

performance.mark(”start-async”);
for (let i = 0; i < 10000; i++) {
generateKeyPair(”rsa”, { modulusLength: 1024 },
() => {});
}
performance.mark(”end-async”);
performance.measure(”generateKeyPair”, “start-async”, “end-async”);

The asynchronous version changes how the work is executed. Instead of occupying the main thread, the operations are delegated, allowing the event loop to remain available. This difference has a direct impact on system responsiveness, especially under load.

The performance gap is not theoretical

The difference between synchronous and asynchronous execution is not just conceptual. The book demonstrates that the impact can be measured and observed in practice. The synchronous version of the operation takes significantly longer and blocks execution entirely.

The asynchronous version, by contrast, allows the system to continue processing other tasks while the work is being performed. This leads to better utilization of system resources and improved responsiveness.

This distinction changes how performance should be evaluated. In Node.js, performance is not only about how quickly a single operation completes. It is about whether the system can continue to process other work during that time.

A fast operation that blocks the event loop can still degrade system performance if it prevents other tasks from progressing. Conversely, a slower operation that does not block may have less overall impact on system responsiveness.

Why this matters more under load

Blocking behavior becomes more problematic as concurrency increases. In low-load environments, tasks are processed with minimal overlap, and delays may not be noticeable. The system appears stable because there is little competition for the event loop.

As the number of concurrent operations grows, the situation changes. Multiple tasks begin to depend on the event loop at the same time. Each task expects to be processed in a timely manner, and blocking operations disrupt this expectation.

When a blocking operation runs, it prevents the event loop from servicing other tasks. These tasks begin to accumulate in the queue, increasing wait times and reducing overall throughput. The system becomes less responsive as more work is added.

This is why blocking issues often appear only under load. The system needs sufficient concurrency for the delays to become visible. Once that threshold is reached, the impact becomes more pronounced, and performance begins to degrade more rapidly.

Async wrappers do not remove blocking

A common misconception is that using asynchronous syntax automatically makes an operation non-blocking. Wrapping a function in async/await or a callback does not change how the underlying work is executed.

The book emphasizes that async syntax controls how results are handled, not how the work itself is performed. If the underlying operation is synchronous and CPU-intensive, it will still block the event loop.

This distinction highlights the difference between code structure and execution behavior. A function may appear asynchronous in form while still behaving in a blocking manner in practice.

Understanding this difference is essential for identifying performance issues. Changing syntax without addressing the underlying execution does not resolve the problem.

Reducing work instead of changing execution

In some cases, improving performance is not about changing how an operation executes, but reducing how often it runs. The book demonstrates this with an example where repeated computation is replaced with a caching approach.

Instead of recalculating an expensive result for every request, the system stores the result and updates it periodically. This reduces the number of times the operation is executed, lowering the load on the event loop.

let cachedSignature = null;
const app = Express();

const signingMiddleware = (_req, res, next) => {
if (!cachedSignature) {
console.info(”Signature is not cached”);
cachedSignature = signData(Date.now().toString());
setInterval(
() => (cachedSignature = signData(Date.now().toString())),
10000);
}

res.setHeader(
“X-Signature”, `data=${cachedSignature.data.toString()};kid=${cachedSignature.keyId};sha512=${cachedSignature.signature}`);
next();
};

This approach shifts the focus from execution style to execution frequency. By reducing repeated work, the system becomes more efficient without changing how the operation itself is implemented.

The real trade-off

Blocking code is often easier to write and reason about. Its linear execution model provides clarity and predictability, making it attractive in many situations.

However, this simplicity comes at a cost in systems that rely on concurrency. Blocking operations limit the ability of the event loop to process multiple tasks efficiently, reducing overall system responsiveness.

The trade-off is not simply between synchronous and asynchronous code. It is between local simplicity and system-wide performance. A piece of code that is easy to understand in isolation may introduce constraints that affect the entire application.

As systems scale and concurrency increases, this trade-off becomes more significant. Decisions that seem minor at the code level can have substantial impact at the system level.

Key Takeaways

• Blocking code prevents the event loop from processing other tasks, creating system-wide delays.

• Synchronous APIs introduce constraints that limit concurrency.

• CPU-intensive operations can block execution even when used with async syntax.

• Performance in Node.js depends on maintaining event loop availability.

• Reducing execution frequency can improve efficiency without changing execution style.

Final Thoughts

Node.js relies on a responsive event loop to handle concurrent operations effectively. Blocking code disrupts this model by introducing delays that affect all tasks, not just the one being executed.

The impact of blocking behavior is not always immediate, but it becomes clear under load. As concurrency increases, the system’s ability to process work efficiently depends on keeping the event loop free.

If you’d like to read more on this, Node.js Design Patterns explores these ideas in depth, especially around asynchronous behavior, performance, and the architectural decisions behind scalable Node.js systems.

This Week in the News

• 🧠 Tokenmaxxing is the new productivity metric developers are gaming: There’s a new habit showing up in AI-heavy workflows. Teams are starting to track and even optimize for token usage, treating it as a signal of productivity. Gergely Orosz digs into why that framing breaks down quickly. More tokens don’t mean better outcomes, just more input. It’s the same pattern developers have seen before with lines of code and story points, now resurfacing in an AI-shaped form. What’s interesting here is not the trend itself, but how quickly it appeared. Even with new tools, the instinct to measure the wrong thing hasn’t changed.

• ⚡ TypeScript 7.0 goes 10x faster with a Go rewrite: The TypeScript team has released the 7.0 beta after spending the past year porting the entire compiler to Go. The result is a version that’s roughly 10x faster than TypeScript 6.0, while keeping the type-checking behavior structurally the same. For developers, that means no major migration or new errors to worry about. Just significantly faster builds out of the box.

• 🟢 Node.js moves toward Temporal API and stabilizes key features: Node.js is preparing to support the Temporal API by default, likely landing in the upcoming v26 release. This brings a modern, more reliable alternative to JavaScript’s existing Date handling into the runtime. At the same time, Node.js 24.15.0 (LTS) marks require(esm), and the module compile cache as stable, and introduces a new --max-heap-size flag. Together, these updates signal continued progress in both runtime capabilities and performance tooling.

• 📧 React Email 6 simplifies a fragmented ecosystem: React Email 6 introduces a major update focused on cleaning up versioning issues across its ecosystem. The release makes it easier to manage dependencies and ensures the CLI and components stay in sync. For teams building email templates with React, this should reduce friction and make the overall workflow more predictable.

Beyond the Headlines

• ⚡ A new Angular compiler built on Oxc: This post explores an experimental Angular compiler powered by Oxc, a Rust-based toolchain focused on performance. The goal is to significantly speed up builds and modernize the compilation pipeline. It’s another signal that JavaScript tooling is steadily moving toward Rust-based infrastructure to push performance boundaries.

• 🚨 Investigating fake stars in GitHub repos: This investigation looks into how some GitHub repositories inflate their popularity using fake stars. It highlights how easily perception can be manipulated and why star counts aren’t always a reliable signal of quality. For developers, it’s a reminder to evaluate projects based on code, activity, and community, not just metrics.

• 🎥 Rethinking modern web architecture: This talk dives into how modern web architecture is evolving, covering trade-offs in performance, complexity, and developer experience. It offers a broader perspective on how current patterns scale in real-world applications. A useful watch if you’re thinking beyond frameworks and into long-term system design.

• 🧩 Features worth borrowing from npmx: This article breaks down specific ideas from the npmx project that could inspire better developer tools. It highlights practical features that improve how developers explore and interact with packages. The takeaway is simple. Good tooling often comes from rethinking small UX details.

• 🛠️ Why app stability matters more than ever: Cursor shares insights into building stable applications, especially in environments where rapid iteration and AI-assisted development are becoming the norm. The focus is on reducing breakage and maintaining reliability as systems evolve. It’s a reminder that speed is valuable, but stability is what keeps users and teams productive.

Tool of the Week

🎬 Add unique animations to your React apps

Building engaging UIs often means going beyond basic transitions. Animata offers a collection of 100+ animation-focused React components, including effects like animated beams, spreading cards, and even a Slack-style intro screen.

It’s a handy resource if you want to add more personality to your UI without building complex animations from scratch.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.

DeerFlow is an open‑source SuperAgent framework based on LangGraph, focusing on multi‑agent orchestration, with 60K+ stars on GitHub. Core contributor Daniel He has long been deeply involved in agent workflow design and stateful graph execution, and he is dedicated to pushing autonomous agents to the true limits of production environments.

This article is a speaker feature for an upcoming FREE live session hosted by Packt, where the DeerFlow team will walk through how these ideas translate into real systems.

Build AI Agents with DeerFlow 2.0

Expect live demos, including agents that review pull requests and generate full research reports from a single prompt, along with a closer look at how DeerFlow coordinates models like GPT, Gemini, and DeepSeek behind the scenes.

The event is designed for engineers, AI practitioners, product teams, and anyone exploring autonomous workflows or open source agent systems. It also includes insights from the maintainers on how the project evolved from DeerFlow 1.0 to 2.0, what is coming next, and how to get involved.

📅 Wednesday, May 6 • 9 AM – 10:30 AM EDT
🌐 Free online event by Packt Publishing

Register now

How exactly can an agent system “continuously become stronger”?

It relies on training data, training infrastructure, and evaluation loops, which makes this kind of continuous improvement a platform-level capability rather than something a typical product team can iterate on frequently.

Recently, Harrison Chase, the founder of LangChain, posted an X thread that breaks down the Agent Continuous Learning system into three layers: Model (model weights), Harness (execution mechanism), and Context (configurable memory). He then combined this with cutting-edge work such as Meta-Harness and LangChain Deep Agents to analyze the learning methods, implementation costs, and applicable scenarios of each layer.

Based on this analysis, a possible action path for product teams is: first, get Traces right, then do Context learning, then establish a Harness optimization loop, and finally consider model fine-tuning.

The core argument of this article is very clear:

For AI agents, “continuous learning” should not be understood as merely updating model weights. An agent system can actually evolve continuously on three levels: Model, Harness, and Context.

Core Framework: Three-Layer Agent Learning

In his thread, Harrison broke down the agentic system into three layers:

• Model: The underlying model itself, which is the weights.

• Harness: The “shell” that drives the model’s operation, including agent code, fixed tools, fixed hints, execution loops, etc.

• Context: A configurable context located outside of the harness, such as memory files, skills, user configurations, and team configurations.

The value of this definition lies in the fact that it expands “learning” from a single model training problem into a complete systems engineering problem.

Layer-by-layer interpretation

1. Model layer: The most traditional, but also the most complex layer.

This layer corresponds to continuous learning, which is most familiar to everyone:

• Update weights using methods such as SFT and RL.

• It is also possible to use a more fine-grained adaptation method, such as LoRA.

• The goal is to make the model perform better on new tasks.

However, an old problem persists: catastrophic forgetting. That is, after the model learns new things, its old abilities actually degenerate.

Daniel’s judgment is:

• For most teams, the Model layer has the highest continuous learning cost.

• It relies on training data, training infrastructure, evaluation loop, and model deployment mechanism.

• This is more like a platform-level capability than a routine method that a typical product team can frequently iterate upon.

So while Harrison acknowledges the importance of the model layer, his real focus is not there.

2. Harness Layer: The most underestimated leverage point in agent engineering over the past year.

“Harness” does not refer to the model itself, but rather “how the model is used”:

• How to write system prompts

• How to expose tools to the model

• How to organize loop calls

• When to truncate the context, when to retry, and when to determine if the task is complete

• Which logs and traces are saved for later analysis

Harrison specifically mentions the work at https://yoonholee.com/meta-harness/ in his article. Its main idea can be summarized as follows:

1. Run the agent on a batch of tasks.

2. Collect complete execution logs and scores.

3. Store these historical candidates, source code, and execution traces in the filesystem.

4. Then, have a coding agent read these materials and propose new harness modifications.

5. Evaluating the new harness and continuing its iterations.

This is important because it illustrates:

• Agent evolution can be achieved without changing the model, only the runtime framework.

• The truly high-value optimization targets are often the “execution mechanism” rather than the “parameters”.

• The more complete the traces, the more harness optimization resembles an engineering iteration rather than a matter of guesswork and prompt adjustments.

The official Meta-Harness page also presents strong results: it emphasizes its key difference by allowing the optimizer to see the complete historical code, scores, and execution traces, rather than just a summary. The authors claim that this “filesystem-level context” can increase the available diagnostic information for each round of optimization by an order of magnitude compared to traditional methods.

3. Context Layer: Closest to the business logic, and best suited for initial implementation

Harrison defines Context as content located outside of the harness used to configure the agent, for example:

• Instructions

• Skills

• Tools

• Memory files

• User preferences

• Team rules

The key to this layer is not “what the model has learned”, but “what the system has remembered and how to continue using it in subsequent sessions”.

The official documentation for LangChain Deep Agents explains this in great detail. It supports:

• Agent-scoped memory: All users share the same agent memory.

• User-scoped memory: Each user has their own independent memory.

• Online update: Write directly to memory during session

• Backend organization: Performing consolidation outside the session

• Skills are a form of procedural memory, loaded only when needed.

This shows that the Context layer is not as simple as “adding more prompts”, but a persistent, hierarchical, readable, writable, and searchable memory system.

Two examples from the author

Harrison used two mappings in the article, first for Claude Code:

• Models: Claude Sonnet, and so on

• Harness: Claude Code itself

• User context: CLAUDE.md, /skills, mcp.json

This breakdown is very practical because it directly illustrates:

• Your perception that “Claude Code has become smarter” may not necessarily be due to changes in the model weights;

• It’s also possible that the harness has been changed;

• Or perhaps you’ve configured its context better;

And again for OpenClaw:

• Model: Can accept multiple models

• Harness: Pi (powers OpenClaw) plus some running scaffolding

• Agent context: SOUL.md and skills from ClawHub

OpenClaw’s public documentation says:

• SOUL.md is officially defined as the personality and tone configuration file for the agent

• ClawHub is defined as a public registry of OpenClaw skills/plugins

This precisely confirms Harrison’s point: the “continuous learning” of many agent systems essentially occurs at the configurable context layer, rather than the model fine-tuning layer.

The paradigm shift this article aims to promote

To summarize this article into a single sentence:

An agent’s continuous learning is shifting from “training the model” to “optimizing the entire system”.

There are at least three changes here:

1. The learning objective shifts from weights to system behavior.

Traditional LLM continuous learning focuses more on:

• Has the loss decreased?

• Has the benchmark improved?

Agent continuous learning focuses more on:

• Are they better at using tools?

• Are they better at planning steps?

• Can we improve our execution strategies by learning from past failures?

• Do we have a better understanding of the preferences of current users, teams, or organizations?

2. The learning unit is shifting from a single model to a hierarchical architecture.

Within the same agent system, the learning frequency and cost of different layers are completely different:

• Model: Low frequency, high cost, platform level

• Harness: Mid-frequency, engineering-driven, measurable

• Context: High frequency, business-driven, most likely to occur online

This means that continuous learning should not have just one master switch, but rather three different mechanisms.

3. Traces become a unified fuel.

Harrison repeatedly emphasizes “traces” at the end of the article. This is one of the most crucial infrastructure assessments in the entire text.

The reason is straightforward:

• To modify the model, you need traces as a source of training/preference data

• To improve harnessing, you need traces as diagnostic material for failures

• To modify the context, you need traces as source material for experience extraction

In other words, without high-quality traces, there is no high-quality agent learning loop.

Some personal judgments

1. The Context layer will be the first to become widespread.

Daniel believes that the Context layer, rather than the Model layer, will be the first of the three layers to be widely implemented.

Reasons:

• No training required

• The most direct impact on business returns

• Isolation can be done by user / team / org

• Easy to manage permissions and rollback

• Easier to meet the controllability requirements of enterprise systems

Many capabilities that are packaged today as “the agent can remember” essentially belong to this level.

2. The Harness layer will become the focus of the next round of agent infrastructure competition.

If 2024 was mainly about who could get their agent up and running first, then 2026 will be more about:

• Whose harness is more stable?

• Whose traces are more complete?

• Whose evaluation and replay system is more closed-loop?

• Who can quickly incorporate failure cases into the next version of agent behavior improvement?

This is why work like Meta-Harness is worth paying attention to. It represents a very engineering-oriented approach: letting the agent help you change the agent.

Practical reflections on your team’s development of agent products

If your team is planning to incorporate “continuous learning” into its agent roadmap, Daniel recommend proceeding in the following order:

Phase 1: First, get the traces right

• Unified recording of task input, tool calls, key intermediate states, output results, and human feedback

• Preserve reviewable evidence for failed tasks, rather than just reporting an error

• Add user/org/task/version dimension tags to traces

Phase 2: Prioritize context learning

• Start with user preferences, team rules, glossary, and standard operating procedures (SOPs)

• Distinguish between read-only memory and writable memory

• Define the scope: which is user-level and which is org-level

• Support both online writing and offline defragmentation update paths

Phase 3: Establish the Harness optimization loop

• Run the agent continuously on a standard task set

• Perform A/B testing and automated evaluation on the harness version

• The coding agent reads traces to help propose candidates for harness modification

• Establish a rollback mechanism to prevent situations where changing the prompt might seem convenient in the short term, but ultimately leads to decreased overall stability

Phase 4: Consider model-level learning only as a last resort

• Only when you have accumulated enough high-quality traces

• Furthermore, optimizations at the harness/context layer are nearing their limits

A reusable decision framework

When faced with the question “How should an agent undergo learning?”, you can first ask four questions:

1. What needs to be changed this time? Is it the model capabilities, the operating mechanism, or the configurable memory?

2. Should this change apply to the agent, user, or org scope?

3. Should this update occur immediately during runtime, or should it be processed in an offline task before taking effect?

4. Are there enough complete traces to support an assessment of whether this learning was truly effective?

If these four questions cannot be answered clearly, the so-called “continuous learning” is most likely just a vague slogan.

Conclusion

The value of Harrison Chase’s post and accompanying article lies not in proposing a completely new algorithm, but in breaking down agent continuous learning into a more practical three-layer framework:

• Model learning addresses underlying capabilities

• Harness learning addresses the execution mechanism

• Context learning addresses memory and personalization

The two things that the product team should act on immediately are not training the model, but rather:

• Build the infrastructure for traces

• Productize the context and harness learning loop

This is also Daniel’s core conclusion for this article: stronger agents in the future will not necessarily come from larger models, but are more likely to come from systems that are better at “reviewing, remembering, and reconstructing”.

Want to know more about how to turn your prompts into workflows with an agent harness? Join us for a live demonstration of DeerFlow 2.0 on 6th May!
Register now!

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.