😬 The React patterns everyone regrets using

The AI Report distills the day's most important AI news into one free 5-minute read. No jargon, no filler — just what 400,000+ business leaders need to know before their first meeting.

Subscribe free today

🔎 React Patterns We All Overused (And Then Regretted)
A great Reddit thread this week asked a simple question: what React pattern did you go all-in on… only to realize it made things worse? The answers hit a familiar theme, we tend to over-engineer in the name of “best practices.”

🧩 Practice Debugging React (Not Just Building It)
BugDojo, a browser-based tool designed to help you actually practice debugging React, something most tutorials completely skip. You’re given broken components, a live preview, and expected output, then fix the code and run tests instantly in the browser. No setup, no installs, just jump in and start solving katas with increasing difficulty, plus daily challenges and streak tracking. It’s a simple idea, but fills a very real gap: learning how to fix React apps, not just build them.

🏗️ Stop Organizing React Code by Type (It Doesn’t Scale)
TkDodo argues most React codebases are structured wrong, splitting into components/, hooks/, and utils/ creates chaos as apps grow. Instead, he suggests grouping code by feature (“verticals”), so everything related to a domain lives together. The benefit is less jumping between files, clearer ownership, and code that evolves together instead of being scattered. It’s harder to set up, but far more scalable, especially for large teams and long-lived apps.

⚛️ React Server Components… Without the Framework Lock-In?
TanStack just introduced experimental RSC support in Start, and the approach is noticeably less opinionated than what most React devs are used to. Instead of making server components the center of your app, they treat them as something you can layer in when it actually helps.

The interesting shift here is philosophical: this feels closer to classic React (flexible, composable, developer-controlled) rather than a full framework dictating how your app should work. RSCs become a tool you reach for, not something you have to build around.

Our documentation assistant had a problem. RAG pipelines only sent the model fragments of pages, never the full picture, making responses feel half-baked. The fix was obvious: give the agent a real sandbox with full doc access. Quality jumped, but startup hit 46 seconds and costs ballooned to $70K+ per year.

The insight: the agent doesn't need a real filesystem. It just needs to think it's in one.

We built ChromaFs, a virtual filesystem that translates standard UNIX commands into queries against our existing Chroma database. Every doc page becomes a file, every section a directory. The agent explores documentation the way a developer explores a codebase.

The results:

ChromaFs now powers our documentation assistant across 30,000+ conversations a day for hundreds of thousands of users. No containers, no cold starts, no invoice surprises.

Try Mintlify today!

Quick Links

🤖 Claude Code Launches Routines
Claude Code is quietly pushing toward a world where chunks of your development workflow run themselves. Its new “routines” feature lets you package a prompt, repos, and tools into an automated agent that can trigger on schedules, API calls, or GitHub events, and keep working even when your laptop’s closed. They also run fully autonomously, meaning your prompt design and scope control suddenly matter a lot more.

😪 AI Is Making Code Harder to Maintain (Not Easier)
One team audited 6 months of AI-generated PRs and found something unexpected: fewer obvious bugs, but a rise in “plausible” code that works yet feels wrong, over-abstracted, harder to read, and eerily uniform across devs. The real issue isn’t correctness, it’s readability and ownership, making code harder to reason about and maintain over time. A great read if you’re going all-in on AI, a reminder that more code ≠ better engineering

🚀 How NASA Built Artemis II’s Fault-Tolerant Computer
For Artemis II, NASA designed an ultra fault-tolerant system where eight CPUs run in parallel, instantly detecting and silencing any faulty output caused by radiation or hardware issues. Instead of trying to fix errors, the system ensures bad data never gets through, using redundancy, strict timing, and a “fail-silent” design. The result is a system that can lose multiple computers mid-flight and still operate safely.