Clay Tercek

Agents Saved React (Unfortunately)

hello@tercek.me (Clay Tercek) — Fri, 29 May 2026 00:00:00 GMT

There's an article making the rounds about AI causing a repeat of frontend's "lost decade." The central claim is that agentic coding tools are "deskilling" developers the way JavaScript frameworks did before them.

Half of that is right.

The deskilling argument actually lands for agentic coding. When an AI writes your code and you accept it without reading it, you don't need to understand what it's doing to ship something. That's a real concern.

But applying "deskilling" to React and the framework era? That's where I disagree. The article's own list of lost skills is worth reading back: semantic HTML, CSS, browser differences, accessibility, progressive enhancement, network performance. That's exactly the list of things a good React developer still has to know. React didn't remove those requirements. It repackaged them into a component model that's more portable and easier to reason about at scale. The skills didn't disappear. The syntax changed. That reads more like "old school dev mad at change" than a real critique.

Anyway. The bigger thing I've been chewing on is React itself.

DX rules, UX drools

I've spent years quietly hoping the frontend world would move on. Not because React is broken. It's not. The developer experience is genuinely excellent. Component model, unidirectional data flow, a massive library ecosystem. You can build anything with it. Slowly, on a bad connection, but anything.

But "you can build anything" and "you should build this" aren't the same claim. The answer to the second one is almost never React.

The performance story has been bad since the beginning. Shipping a runtime to the browser to reconcile a virtual DOM with the actual one is a strange thing to make the default, especially once browsers got good at the exact job React was hired to do. The virtual DOM was always a tradeoff, not a free win. And the framework made that tradeoff on the user's behalf, not the developer's. Bundle sizes ballooned. Time to interactive got worse. Developer experience kept improving while user experience slid in the other direction.

We were so close

Here's what's annoying: fine-grained reactivity has existed for years. Svelte figured this out. You write components, the compiler produces lean output, there's no virtual DOM to reconcile. It's faster. The bundles are smaller. The expensive work happens at build time instead of in the user's browser. Svelte is excellent, and I genuinely enjoy working with it.

Solid went further and asked: what if you got Svelte-level performance but kept React's mental model? Signals, composable primitives, JSX. Turns out you can have both. Solid routinely lands near the top of the framework benchmarks, right next to vanilla JavaScript. Solid is a great framework. Nobody uses it.

Preact shipped signals for the same reason back in 2022. And the React Compiler that Meta shipped in late 2024 is trying to automate, at build time, the memoization that compiler-first frameworks made unnecessary half a decade earlier. It doesn't touch the core issue: the runtime and the reconciler still ship to the browser, and the compiler just re-renders less of the tree. It's a stopgap with good marketing.

Around 2023 and into 2024, there was real momentum behind the idea that React would stop being the default. Not die. Just become one tool among several, chosen when it's actually the right fit. SvelteKit was getting attention. Solid was maturing. The conversation felt like it was actually happening.

Then agents happened

When an AI is writing your code, it writes what it knows best. Models have more React training data than anything else in the frontend space, the patterns are exhaustively documented, and the community is enormous. Ask an agent to scaffold a component and you're getting React, a useEffect that fires twice in development, and a package.json with thirty dependencies. That's not a criticism, it's just how it works.

It's not even subtle. Someone asked eight different models and tools to build a frontend: Claude, GPT, Gemini, DeepSeek, Qwen, v0, Lovable, Bolt. They all landed on nearly the same answer. React, Next.js, TypeScript, Tailwind, shadcn/ui. The stack is a property of the training corpus, not a choice. And because the next model trains on the code this one generates, the corpus skews further toward React every cycle. The default reinforces itself.

So instead of the frontend world diversifying, it consolidated. React got a massive tailwind. Not the CSS kind.

Svelte and Solid are still out there and still measurably faster. They're just not what the agent defaults to.

What bothers me most is the timing. Svelte 5 shipped with runes in October 2024. SolidStart hit 1.0 that May. Real alternatives existed with real communities. The moment when developers might have started making deliberate, performance-conscious framework choices arrived right as the era of developers writing code by hand started winding down.

AI coding tools get marketed as accelerators of innovation. But if you're generating the same patterns from three years ago at ten times the speed, that's not innovation. It's just more of the same, faster.

The lost decade is here. It just comes with better autocomplete.

AGENTS.md Is Not a README

hello@tercek.me (Clay Tercek) — Wed, 27 May 2026 00:00:00 GMT

Open source projects are getting plagued by agent files. AGENTS.md, CLAUDE.md, .cursor/rules, .github/copilot-instructions.md, committed skills, the works. The convention, pushed hard by the people who make these tools, is to commit them. The agents.md spec frames the file as "a README for agents," project infrastructure that belongs in source control next to your CI config. GitHub has written up lessons from 2,500+ repos treating it as shared documentation.

I think this is mostly a mistake.

These files are inherently personal. The way I drive an agent is not the way you drive an agent, and committing my workflow into a shared repo quietly assumes the whole team should converge on one. I don't think that's true, and I don't think it's desirable. Your agent workflow can and should be bespoke. It's closer to your editor config or your shell aliases than to your test suite. Nobody commits their .vimrc to the project repo and expects everyone to adopt it.

The usual argument for committing the file is that it documents the architecture, the repo layout, the build and release process, the conventions a new collaborator needs. All of that should be shared. But none of it is agent information. It's documentation, and documentation belongs in the README, where humans will actually read it. Putting it in AGENTS.md just hides your project docs somewhere only the robots look. As spawarotti put it on Hacker News:

"At this point AGENTS.md is a README.md with enough hype behind it to actually motivate people to populate it with contents. People were too lazy to write docs for other people, but funnily enough are ok with doing it for robots."

The shareable content was never agent content. It's the docs we should have been writing for each other all along.

This instinct isn't fringe, but it's a minority position. You can watch the debate play out in real time: a Hacker News commenter says flatly, "I would .gitignore all of those files. Is this not what is done in industry?" and gets mostly disagreement. The split is always the same: shared rules enforce consistency, but they also flatten everyone into one person's setup.

So why does everyone commit them anyway?

Because the alternative is genuinely worse right now.

The reason to colocate agent instructions with the code is that git gives you branch-awareness for free. Say you're on a feature branch and you tweak AGENTS.md to describe a module that only exists on that branch. Then you switch back to main. Because the file is tracked, your changes travel with the branch, so main's agent never sees references to code that doesn't exist yet. Anyone who has tried git-ignoring their agent files knows the opposite feeling: a single global instruction file that's perpetually slightly wrong for whatever branch you're actually on.

So you're stuck between two bad options. Commit the file and impose your workflow on the team, or ignore it and lose the branch-awareness that made it useful.

What we have today

The tools do offer escape hatches, they're just incomplete.

Claude Code, for instance, has a real hierarchy (documented here): a user-level ~/.claude/CLAUDE.md that applies across all projects and never gets committed, a team-shared project ./CLAUDE.md, and a personal ./CLAUDE.local.md that you're meant to add to .gitignore. AGENTS.md has an open proposal to standardize a global ~/.config/agents/AGENTS.md, explicitly modeled on how git handles ~/.gitconfig versus a repo's .git/config.

That git analogy is the right one. Git solved exactly this problem decades ago: global defaults in ~/.gitconfig, repo overrides in .git/config, and personal per-repo ignores in .git/info/exclude that never touch the shared .gitignore. The local layer is never committed. We just haven't fully ported that model to agent memory.

The gap is branch-awareness. CLAUDE.local.md is per-worktree, not per-branch. None of the personal-config options track your branches the way a committed file does.

That gap is what pushed me to build offstage, a small Go CLI that keeps personal files colocated with a project without committing them to the project's repo. It's backed by a separate private git repo, and it's branch-aware: files are stored under <project-id>/<git-branch>, so each branch gets its own notes, synced across machines via git hooks. It's been working for me, but I'm floating it as one option, not a recommendation, and your mileage may vary. It's a partial fix at best: if a branch gets merged via a PR, offstage has no way to know, so you have to manually run offstage merge to reconcile. The branch lifecycle and the file lifecycle drift apart the moment the merge happens somewhere offstage can't see.

A better solution

The real fix is more foundational than a sync tool. A few directions I think are worth exploring:

Native per-branch personal memory in the agent itself. The agent already knows what branch you're on. It could keep personal instructions keyed by branch, stored outside the repo, and reconcile on branch events (merge, delete, rebase) by hooking into git the way it already hooks into everything else. This is offstage's job, done by something that can actually observe the merge.
A standardized local layer, universally honored. If every agent agreed on a ~/.config/agents/ global file plus a gitignored local override, and actually merged them at runtime, most of the "personal vs. shared" tension disappears. The committed AGENTS.md becomes a genuine team README; everything bespoke lives in your local layer.
Treat the shared file as the floor, not the ceiling. Commit only the truly project-wide facts (build commands, test runner, deploy steps) and socially discourage stuffing personal workflow into it. Keep the file boring and uncontroversial on purpose.

None of these fully exist yet. For now I commit a deliberately minimal AGENTS.md and keep everything bespoke in offstage. But I think the long-term answer is for agents to treat memory the way git treats config: layered, with the personal layer kept firmly off the shared record.

References

agents.md — the open spec, now under the Linux Foundation's Agentic AI Foundation
Claude Code memory docs — the user / project / local hierarchy
agents.md issue #91 — proposal for a global user-level AGENTS.md
HN: "I would .gitignore all of those files"
HN: spawarotti, "AGENTS.md is a README.md with enough hype"
git-scm.com/docs/gitignore — .git/info/exclude and core.excludesFile
offstage — my attempt at the branch-aware personal layer

Cache the HTML Too

hello@tercek.me (Clay Tercek) — Tue, 26 May 2026 00:00:00 GMT

A lot of web frameworks and platforms bury the single easiest way to make a site faster and cheaper: CDN caching. We spend enormous effort shaving milliseconds off server-side rendering, picking the fastest meta-framework, optimizing database queries, and then skip past the one move that beats all of it. Just save the result. There's no reason to repeat the same work on every single request.

The fastest request is the one your server never sees.

HTML is cacheable too

Most CDNs make this trivial, but the default trips people up. Cloudflare, Fastly, CloudFront, Vercel's edge: they all cache your static assets (CSS, JS, images, fonts) out of the box. What they do not cache by default is HTML. As Cloudflare's docs put it plainly: "The Cloudflare CDN does not cache HTML by default."

That's the part people miss. Caching media feels obvious, but caching pages feels dangerous. Yet a huge fraction of the HTML you serve is identical for every visitor, and there's no reason to render it fresh each time.

Turning it on is mostly a one-liner. The mechanism across every CDN is the Cache-Control header: s-maxage controls how long the CDN holds the response, and stale-while-revalidate lets it serve the stale copy instantly while refreshing in the background. On Cloudflare you can also do it without touching your app, via a Cache Rule that marks matching URLs as eligible for cache.

One real caveat: "cache everything" means everything. If you blanket-cache HTML, you can hand one user's logged-in page to the next visitor. So scope it: exclude anything with an auth cookie, exclude your dashboard, cache the public pages. Anything that sets Set-Cookie, private, or no-store is skipped automatically, but you should still be deliberate about it.

How much of your site actually needs to be fresh?

This is the question worth asking before you reach for anything fancier. Your blog, your marketing pages, your docs, your product listings... how often do they really change? Sure, modern frameworks render pages fast. But "fast to render on every request" will always lose to "already rendered, sitting at an edge node 20ms from the user." Static beats dynamic, and a cache turns dynamic into static for the 99% of requests where nothing changed.

A note on framework caching

Frameworks have their own caching layers, and it's easy to conflate them with CDN caching. Next.js is the instructive case because its caching model is famously confusing.

Next.js has several distinct caches: Request Memoization (dedupes calls within a single render), the Data Cache (persists fetch results across requests), the Full Route Cache (server-side), and the Router Cache (client-side). The Full Route Cache serves fully rendered static pages straight from cache: at build time Next.js renders static routes to HTML plus the RSC payload, and serves that cached output instead of re-rendering per request. That's exactly the static-serving behavior you want.

Server Actions are not cached. They use POST and are mutations by design; Next.js only ever memoized GET-style data fetches. Actions can trigger invalidation via revalidatePath / revalidateTag, but they're never served from cache.

Worth knowing too: Next.js 15 flipped the defaults toward less implicit caching: fetch is no-store by default now, and GET route handlers aren't cached by default. The framework is leaning away from caching-by-magic, which makes the case for owning your caching at the CDN layer even stronger.

None of this means Next.js is bad at caching. The point is that framework caches and CDN caches solve overlapping but different problems, and the CDN layer is the portable one. It works the same no matter what you build with, and it's hard to beat for the effort it takes. Reach for it first.

References

Cloudflare: default cache behavior — what gets cached out of the box, and what doesn't
Cloudflare: "Cache Everything" via Cache Rules
Next.js caching guide — the four cache layers, explained
Next.js 15 release notes — the caching default changes
MDN: Cache-Control — s-maxage, stale-while-revalidate, and friends