X / Twitter
prediction:
agent frameworks are going to race to implement ai-generated workflows next
e.g. dynamic workflow for production apps https://t.co/aJp8tdR0KL
@GergelyOrosz you mean loads of people building lore?
https://t.co/gRG03mdGeX
One interesting trend:
I’m seeing *so many* VC-funded, internally built infrastructure and bootstrapped solutions around “building a context layer for engineering teams.” Aka trying to solve the problem of “if only eg Claude Code had the context from all your other systems”
If you're on your way to building a billion dollar company that involves a web app, here are some of my notes on architecting the frontend.
if you don't do this, it's probably fine but one day you'll hire someone to fix it but truly that person could be doing some other higher value thing if you make some key optimizations on day 1
you don't even have to learn anything you're gonna tell your agents to do it anyways!
okay here it goes:
- Make your server code generate a openapi spec which then generates all the relevant client side code. Never do this by hand. Typing backend types instead of generating them should be banned
- You need to make a decision on how the client talks to the backend. rest/graphql works in which case please just use tanstack query. other libraries will look similar but tanstack query truly is goated.
- if you want linear style sync setups or offline mode, think about this HARD and architect it from day 1. Bolting this on later is so tedious.
- People like using plain react router but things have gotten a lot better since then. Try their new framework mode or just even use tanstack router. Use route data loaders.
- If you store a lot of state in query params, make that a first class citizen and make sure its type safe. use nuqs or tanstack query.
- Most apps just need a single state management situation for server state and thats it. If you have other bespoke needs, i have quite like zustand and xstate/store.
- If you have a super interactive app where things come in and out of view, theres a lot of frontend state to maintain, music is playing and what not, lock in and learn xstate. Trust me if you wanna keep ur sanity, you need to model ur frontend as a state machine otherwise you're gonna be deep in useEffect hell
- React compiler is here my friends, the days of useMemo and useCallback are gone. Update your priors accordingly
- Tailwind is easy and fun but makes it really hard to maintain a large app with consistent styling. You need a "agent-first design system/component library" but maybe this is a rant for another day
- Don't be afraid to hack your routing library to fit your needs more closely. A lot of apps have "drawers" to show additional info. You should 100% be able to say "here's a route, make it a drawer" and everything should be handled from there.
- Managing loading and error states using isPending and isError is madness. Lean into Suspense and ErrorBoundary.
- Figuring out a blessed path for websockets and SSE on day 1 i think will pay dividends in the long term if you're building anything AI related.
- If you're building a SPA, don't use next.js. it literally makes no sense. Why would you do this.
- Definitely deploy on Cloudflare or vercel. There are other services but trust, there have weird missing features.
- Assuming you build something people want, the next job is to build the factory so it can efficiently build the thing. Act accordingly.
Just launched Loop Library - a curated list of agent loops you can use right now.
Find loops, submit your own, tokenmaxx!!
https://t.co/7bVzOyZMrt
I've made a Kubernetes that runs in the browser, and today we're open sourcing it.
The hope here is to make super interactive and visual web content about Kubernetes much easier to write, and we have a whole bunch planned this year.
Links below. https://t.co/mbGwb8QTkU
Announcing mattpocock/skills v1
- Achieved a 63% reduction in token cost for skill descriptions
- Split skills into model-invocable and user-invocable skills, adding /codebase-design, /domain-modeling, and /grilling
- (UPDATED) /writing-great-skills - rewritten from the ground up, encoding my skill-writing best practices
- (UPDATED) /diagnose -> /diagnosing-bugs - now model-invocable, awesome for fixing hard bugs
- (NEW) /ask-matt: a router skill that teaches you how all the engineering skills work together
it remains super odd to me that none of the existing agent frameworks, Mastra, Flue, or now Eve seem to do anything about getting context into the agent?
every team that i talk to who are designing agents at-scale need to figure out how to get the enterprise data *to* the agent, which requires carefully planning ETL, evaluating how well the agent performs with different data formats, running things like map-reduce
and yet, every one of the agent frameworks just... leaves this to user with no opinion on it?
maybe you can only do this part with a fully-owned storage layer, idk
what about a knowledgebase platform built using Durable Objects+ CRDTs for realtime edits, artifacts to make it git clonable, MDX + RSC so you can build custom components into the wiki platform itself, and then Dynamic Workers to isolate the custom components
could be agentic af
Some thoughts on ownership I shared with the team this morning https://t.co/WMXcDLU9qa