Hi friends đź‘‹ Happy Tuesday! This week's issue of Frontend at Scale is coming to you a couple of days later, as I needed some time to recover from the family spring break trip this past weekend. If you're wondering why I need time to recover after just coming back from a break, you clearly haven't met my kids.
But don't worry, it wasn't all meltdowns and overpriced mac-and-cheeses that my kids barely touched. I also had some time to catch up on my reading and enjoy a few articles that had been sitting on my Raindrop for a while.
One such article was this great essay by Christopher Meiklejohn on how software engineering is becoming civil engineering. He draws some interesting parallels between what software engineering is going through right now and the transition the building industry went through in the 18th century, when the discipline split between those who did the actual building (e.g., welders building bridges) and those who did the designing (e.g., civil engineers).
I know that comparing the AI revolution with something that happened 300 years ago sounds... let's just say a bit out of touch, but some of the resemblances truly make a lot of sense. Particularly, the fact that making the building accessible to more people only highlighted the importance of the design:
People who’ve never written a line of code are describing what they want, the AI writes it, they verify, it ships. The feedback loop is tight and the results are surprisingly good.​But someone has to design the bridge. Someone has to decide how the database schema handles multi-tenancy. Someone has to design the deployment pipeline so a bad change rolls back automatically. Someone has to build the abstraction layer that lets a product manager add a new notification type without accidentally breaking the payment flow. That’s the platform engineer. The structural engineer of software.
This resonates with my own experience. I'm finding that an increasing percentage of my time is dedicated not to building the feature itself, but to building the system or platform that will make building the feature (and others like it) easier in the future, either by a human or an autonomous agent. Christopher goes on:
Today, most software engineers spend the majority of their day writing features. Tomorrow, I think the best ones will spend their day designing the systems that make it safe for anyone to ship features. [...] I’m not writing much code anymore. I spend my time with the AI directing the platform direction. What are the domain boundaries? What needs isolation? Where do we need observability? How does the system heal itself when something goes wrong? That’s the job now.
This makes sense, right? And it's certainly more reassuring than the alternative of having our jobs completely automated. But... is this how things will actually play out?
Some argue that we can't make parallels between AI and past industry revolutions because AI is so much bigger and faster and different from anything that has ever happened that no comparison can ever make sense. And maybe they're right. Maybe this future in which our jobs evolve to civil engineers makes sense to us only because we want it to be true. But in a world where nobody knows what's going to happen next month, let alone 5 years from now, I believe optimism is the only sensible choice.
I'm not talking about blind optimism here, though. We don't want to be like the dog from the meme, sipping our coffee and saying "this is fine" while the room is visibly on fire. But choosing optimism gives us the control we need to adapt as our jobs continue to evolve. As optimists, we can trust that the room will not catch on fire in the first place—even though the wind seems to be blowing that lit candle dangerously close to those curtains.
Alright, we have a lot to chat about today. Let's get to it.
THIS WEEK IN FRONTEND
TanStack AI Goes Code Mode ON
If you ever thought, "Man, I wish AI could do math as well as my beat-up calculator from the 1980s," then the recent release of Code Mode for TanStack AI might be just what you're looking for.
Wait, TanStack does AI now? In case you missed it among the ever-growing list of libraries in the TanStack Cinematic Universe, the suite now includes a pretty sweet package for building fully type-safe (of course) AI tools using the client, server, and LLM provider of your choice. TanStack AI is useful for building general-purpose agents and ChatGPT-like experiences into your own product.
Speaking of ChatGPT, if you ever asked it a math question and shook your head in disbelief at how confidently it gave you the wrong answer, then you know exactly what problem Code Mode aims to solve: LLMs are great at a lot of things, but math is definitely not one of them.
With Code Mode, instead of letting the LLM pull answers out of its... *ahem* training data, and hope it's even remotely close to being right, you can instruct it to write a small TypeScript script to compute the answer, which TanStack AI then safely executes in an isolated environment. This gives you more reliable results, and a few neat benefits:
- It's more efficient. If you connect your LLM to an API, Code Mode can help solve the N+1 problem by batching and parallelizing network requests instead of making sequential tool calls.
- It's more accurate. You can let LLMs do basic math for things like calculating averages or counting how many Rs there are in strawberry the old-fashioned way, so they give you the same results every time.
- It can be faster and cheaper. Code Mode can help you save some $$$ by reducing the number of tool calls and tokens required to compute an answer. It can also remember useful scripts via persistent skills for even more efficiency.
If you'd like to see it in action, Jack Herrington from the TanStack team has a nice video overview of Code Mode on his YouTube channel. You can also try it on your own projects today, but keep in mind that TanStack AI is still in Alpha, so you probably shouldn't use it in products with real use... You already shipped it to production, didn't you? Oh well.
🛠️ THE TOOLBOX
​Starwind UI v1.16 — Animated, customizable, and accessible components for your Astro projects. It's like shadcn/ui for Astro, built with vanilla JS, and complete with dark mode and full CLI management.
​Boneyard v1.7 — A pretty cool library that automatically generates (at build time) skeleton components based on the real shape of your UI.
​caveman — "🪨 why use many token when few token do trick." A hilariously effective Claude Code skill that helps you save up to 75% of output tokens by talking like a caveman. Btw, if you're looking for an excuse to talk like a caveman in real life, I highly recommend getting a copy of Poetry for Neanderthals, one of the funniest party games you can find these days.
​Impeccable: Design fluency for AI harnesses — Tired of purple gradients and side-tab cards? Same. Impeccable is a set of 18 commands that can help you build UIs that don't scream they were AI-generated.
OPEN TABS
Links Worth Clicking On
- I know we just dedicated an entire section to TanStack, and no, I promise Tanner did not sponsor this issue of the newsletter, but this is pretty big news not to share: TanStack Start now supports​ React Server Components. This means that you can now build any web app in the interactivity spectrum with TanStack's full-stack framework, from fully dynamic to fully static, and everything in between.
- I had the pleasure of attending the Pragmatic Summit conference in San Francisco last month, where the main topic of discussion was "cybersecurity in the age of deterministic software."... Ok, that was a lie. Of course it was AI. My favorite talk at the conference was the panel Gergely moderated with Martin Fowler and Kent Beck, and you can watch it fully on YouTube right now.
- Birgitta Böckeler wrote a great primer on Harness engineering for coding agent users on Martin Fowler's blog, answering all your burning questions about agent harnesses. You know, things like, "What exactly is a harness again?"
- Dan Neciu tells us that, unless we're syncing our React components with an external system, we really, really, really don't need an effect.
- If you took a break from trying to keep up with everything that happened in JavaScript-land this past year, you can get up to speed pretty quickly with Chris Coyier's What To Know in JavaScript (2026 Edition).
- Anton Zaides wrote about the unwritten laws of software engineering, including "Backups aren’t real until you’ve restored from them," "There is nothing more lasting than a temporary fix," and five other laws that may or may not make you relive some deep and painful memories.
- The one and only Bramus released view-transitions-toolkit, a set of utilities to make it easier to work with the View Transition API.
- 🌙 This has been shared virtually everywhere at this point, but in case you haven't checked them out yet, the images from the Artemis II Lunar Flyby are absolutely stunning.
That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d ​share it​ with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)
Did someone forward this to you? First of all, tell them how awesome they are, and then consider ​subscribing​ to the newsletter to get the next issue right in your inbox.
I read all of your comments. Feel free to reach out on ​Twitter​, ​LinkedIn​, or reply to this email directly with any feedback or questions.
Have a great week đź‘‹
– Maxi