The shifts worth knowing about

Stop thinking in keystrokes and start thinking in tasks. Give the agent one tightly scoped instruction plus the context it needs: a conventions file (CLAUDE.md or a rules file) and tests it can run to check its own work. Then treat every diff like a pull request from a junior — read it, don't rubber-stamp it. Keep changes small and commit often so a bad run is one revert away. Let the agent run the edit-test-fix loop on its own, but keep a human on the merge button: work on a branch, never let it push to main unattended, and glance at any command before it executes.

Related tools

Your agent's output is downstream of this file. Two people on the same repo with different rules files ship different code — so if the rules aren't in the repo, quality is non-deterministic and walks out the door with whoever wrote them. It's also the cheapest lever you have: no model swap or fine-tune moves quality the way a tight rules file does, because the alternative is the agent guessing your conventions and propagating the guess across a dozen files before you notice. And it's a real safety surface — the "never touch .env," "never force-push," "never delete a failing test" lines live here, not in someone's head.

Get it out of .gitignore and commit it, then review changes to it in PRs exactly like code — because it changes what the code becomes. Keep one source of truth: write the real rules in AGENTS.md or CLAUDE.md and make the tool-specific files (.cursor/rules, copilot-instructions.md, .windsurfrules) one-line pointers or symlinks so four copies never drift. Keep it under ~200 lines, imperative and checkable ("MUST", "NEVER"), and spend the budget on what the agent can't infer: your resolved stack decisions, the exact verify commands, the never-touch list. Then maintain it like code — add a rule the second time the agent repeats a mistake, delete a subsystem's rules in the same PR that deletes the subsystem, and give the file an owner.

Related tools

AI collapsed the time from idea to live, paid product to a weekend — and a product born on the internet is global on day one. Having paying customers in 40 countries your first week used to be a fantasy; now it's a Tuesday. That moves the bottleneck off building and onto the boring legal surface underneath: EU VAT has no threshold for digital goods, US economic-nexus rules trip in dozens of states, and more countries bolt on digital-services taxes every year. Stripe Tax will calculate what's owed, but you're still the merchant of record — meaning you personally have to register and file in every jurisdiction, which is a full-time compliance job, not a checkbox. Getting it wrong isn't a rounding error; it's back-taxes, penalties and frozen accounts. An MoR turns "register and file in N jurisdictions" into one integration and one payout — the difference between a side project you can actually run and one that quietly becomes an accounting department.

Default to a merchant of record for anything digital you sell to a global audience — subscriptions, downloads, licenses — unless you already employ finance staff. Reach for raw Stripe only when you need full control of checkout, marketplace/Connect payouts, physical goods, or you're big enough to run tax compliance yourself (remember: Stripe Tax calculates, you still register and remit — that's the whole catch). Picking one: Polar or Lemon Squeezy for indie and dev-focused SaaS and digital products (Polar is open-source, dev-first, with license-key and entitlement support); Paddle when you're a real SaaS scaling worldwide; Gumroad for a dead-simple single-product buy button. Treat the ~5% fee as the price of not learning international tax law — cheap until you hit serious revenue, at which point re-run the math and weigh moving to Stripe plus an accountant. Critically, decide the model before your first paying customer: migrating billing after you have active subscribers is genuinely painful, so don't plan to bolt tax on "later."

Related tools

The thing that used to make Postgres painful on serverless was connections. A traditional Postgres box holds a few hundred open connections; a bursty serverless or edge function opens a fresh one per invocation and exhausts the pool almost immediately. Serverless Postgres fixes this at the source with built-in pooling and HTTP/WebSocket drivers that don't hold a socket open, so a Vercel function and a genuine relational database finally coexist without "too many connections" crashes. On top of that, scale-to-zero means an idle side project costs nothing, and branching gives every preview deploy and every test run its own throwaway copy of the database — which is exactly the fast, disposable, try-it-and-see loop that AI-assisted coding runs on. The net effect is that most of the old reasons to reach for a bespoke NoSQL store on a new project have evaporated: you get ACID transactions, foreign keys, JSONB, full-text search, and pgvector for embeddings in one engine you don't have to operate.

Default to Postgres, and specifically to a managed serverless one. Pick Supabase when you want auth, storage, and realtime batteries included; pick Neon when you want a pure database with the best branching story. Don't self-host RDS or hand-roll a NoSQL schema for a new AI-built app "to save money" — you pay it back in connection bugs and migration pain. On serverless or edge runtimes, always connect through the pooled connection string or the provider's HTTP driver (like @neondatabase/serverless), never the direct connection, or you'll drown under load. Put Drizzle ORM (or Prisma) on top so you get a typed schema and real migrations — that way your AI agent edits a schema file it can reason about instead of guessing at raw SQL. Wire a database branch to each preview deployment so migrations run against production-shaped data before they merge. And use pgvector inside the same database for your first AI features rather than bolting on a separate vector store until you've genuinely outgrown it.

Related tools

The trends route (src/routes/library.trends.tsx) reads from this array and previously rendered an empty state; the note is now live-ready. relatedTools names were verified against src/lib/library/tools.ts so ToolChips resolves each to a real library/tool page rather than a dead plain chip, and tsc --noEmit reports no trends-related type errors.

No further action needed to render — the route already maps TRENDS to the page. If you want to keep the note honest to that voice, the key claim to preserve is the tradeoff (you own maintenance, so upstream fixes don't arrive via version bumps) and the practical default (start with shadcn/ui via CLI + commit the files; keep behaviour on installed Radix/Base UI/React Aria primitives; edit copied code with v0/Cursor). Add more notes by appending further Trend objects to the same array.

Related tools

The felt quality of an app is latency, and local-first apps feel instant because the UI updates before the network round-trip instead of after it. Offline support, real-time collaboration and multi-tab consistency then come along mostly for free, because under the hood they are all just "sync." The honest trade: a sync engine is stateful infrastructure with real failure modes — merge conflicts, schema migrations, partial-replication bugs — that are harder to reason about than a stateless REST handler. It is better UX, not a free lunch.

Don't build sync yourself — hand-rolled optimistic updates bolted onto a REST API is exactly where these projects drown. Pick a sync engine and let it own reconciliation. Want the fastest path with no existing database? Use Convex, where reactive queries and sync are the default rather than an add-on. Already have Postgres and want to keep it? Stream a scoped subset down to local SQLite with ElectricSQL or PowerSync. On the client, TanStack DB gives you reactive collections with optimistic writes that sit on top of any of them. Convert one high-interaction view first — a board, an inbox, a settings panel — before you touch the whole app, and scope synced data per user or tenant from day one, because pulling entire tables to every client is the classic way local-first blows up.

Related tools

Here's the honest part the hype skipped: the edge won as a programming model, not as a deployment map. The industry already corrected the "run everything in 300 locations" cargo cult — that's exactly why Vercel shipped Fluid compute and Cloudflare made Workers Node-compatible. Pure edge isolates were too constrained for real apps, and compute far from your database is slower, not faster: the round trips to a single-region Postgres eat every millisecond you thought you saved at the edge. What actually became the default is portable, stateless, web-standard code — plus databases that stopped fighting statelessness. Neon's serverless driver, Turso/libSQL, PlanetScale, and Upstash all speak HTTP, so a function anywhere can reach them without a connection pool. The real payoff is optionality: you write once and decide where it runs based on data locality, not on where the demo looked coolest.

Default to web-standard APIs — fetch, Request/Response, Web Streams, URL. Treat Node-only built-ins (fs, node:net sockets, native addons) as a deliberate choice that pins you to one runtime, not a reflex. Use HTTP/serverless database drivers (Neon serverless, Turso, Upstash) instead of assuming a long-lived TCP pool; if you genuinely need pooled TCP, run that code in a region next to the database, not at the edge. Put stateless, latency-sensitive work at the edge — auth and session checks, redirects, feature flags, geolocation, caching, request rewriting; that's what middleware is for. Keep data-heavy and Node-dependent work in a region co-located with your data. And stop treating "deploy to the edge" as the goal in itself: co-locate compute with data, measure real p95 latency, and let the portable code move only if the numbers say so. Build on something like Hono or Next so flipping the target is a config change, not a rewrite.

Related tools

The differentiation was never the vector search. Teams burned months on HyDE, sentence-window retrieval, and elaborate re-rank pipelines chasing a few points that a long-context call or a managed store would have matched. Boring is good precisely because it frees your attention for the things that actually move quality: your data, your evals, and your product. It also means you ship a working answer engine in an afternoon instead of a sprint, and the next person to touch the code can actually read it. The failure mode in 2026 has flipped — it's over-engineering, not under-engineering. The common mistake now is building a five-stage retrieval pipeline for a corpus that would fit in a single prompt.

1) Start with the dumbest thing that could work. If your corpus fits in a long context window (roughly a few hundred pages), skip retrieval entirely — put the documents in the prompt and lean on prompt caching so you aren't paying full freight every call. Measure whether that clears the bar before you build anything. 2) When it genuinely doesn't fit, reach for pgvector in the Postgres you already run (Supabase turns this into a checkbox). Don't stand up a dedicated vector database until you've hit a real, measured limit — not a hypothetical one. 3) Take the boring defaults. Chunk on document structure (headings and paragraphs, not arbitrary token counts), use a current managed embedding model, retrieve top-k. Add a re-ranker (Cohere Rerank) only when your evals show it earns its latency. 4) For open-ended queries, let the model retrieve as a tool — agentic retrieval where it decides when and what to search — instead of blindly prepending context to every request. 5) Spend the time you just saved on evals and data hygiene. A small labeled eval set that tells you the moment retrieval regresses is worth more than any clever chunking trick you'll read about this quarter.

Related tools

Vibe coders ship fast and don't read every line the AI writes — which means you need an automated reviewer that runs on every edit, and the type checker is the cheapest one you'll ever get. It catches exactly the class of mistake LLMs are most prone to: plausible-but-wrong field names, a renamed column that's still referenced in six places, a shape that's almost right, an unhandled null. In a fully typed stack, renaming one DB column lights up every broken call site from the query down to the component prop, so you find out at edit time instead of in production. It also tightens the agent loop: the model runs `tsc`, sees the red, and fixes its own hallucinated fields before you ever open the app. Untyped JS glue is now a liability precisely because it gives the AI nothing to check itself against — the errors just fall through to your users.

Pick a stack where types flow end to end and never break the chain: Postgres via Supabase or Drizzle ORM, typed queries (Drizzle infers types straight from your schema — no raw SQL strings), a typed network boundary via tRPC or Next.js typed Server Actions, and React components with inferred props. Turn on TypeScript strict mode and treat it as non-negotiable: `"strict": true` plus `"noUncheckedIndexedAccess": true` in tsconfig. Validate every piece of external input — form data, webhooks, third-party API responses — with Zod, and infer your static types from the Zod schema so there's one source of truth, not two that drift. Prefer generated types (Drizzle's inference, Supabase's `gen types`) over hand-written interfaces that duplicate your schema. Make `tsc --noEmit` a required check in CI and, ideally, a step your AI agent runs after every batch of edits. And police the escape hatches: when the model reaches for `any` or an `as` cast, that's a smell — make it stop and type it properly, because every `any` is a hole the type checker can't see through.

Related tools

The terminal already had everything an agent needs — filesystem, git, package managers, compilers, test runners, SSH — with no plugin API to reimplement and no editor sandbox to fight. IDE extensions had to rebuild all of that behind a proprietary surface; the shell just has it. It's also headless and scriptable, so the exact same agent runs on your laptop, over SSH on a box, in a Docker container, and in CI — which is why agents jumped from "chat panel bolted onto your IDE" to "process running in a loop." It's composable in the Unix sense: background it, pipe it, fan out several across git worktrees. And because it's editor-agnostic, your agent stops being locked to one vendor's app. The real cost: the agent now runs live, destructive commands, so permissions and approvals became a first-class design problem instead of an afterthought.

Treat a terminal agent as a primary tool, not a demo. Give it a project config it reads on every run — CLAUDE.md or AGENTS.md — with your conventions, the exact build/test/lint commands, and the things it must never touch; this file is now where team knowledge lives, so commit it. Configure an allowlist so safe commands (tests, typecheck, reads, git status) run without prompting while destructive ones (rm, force-push, DB migrations, deploys) still stop for you. Use git worktrees to run several agents in parallel on separate branches without collisions. Push the loop headless — run agents in CI or as background jobs for triage, dependency bumps, and first-pass PR review — and always give the agent a way to verify its own work (run the tests, read the output) rather than trusting the diff. Version-control the config, skills, and slash commands so the whole team gets identical agent behaviour.

Related tools