Thoughts on technology choices in the AI era

Hi, I’m luckySnail. Lately I’ve been working on two things: first, adjusting the tech stack of the projects I’m responsible for so AI agents can get work done inside them more easily and verify their own work; second, optimizing my toolchain so this 16GB machine freezes a little less often. Every time Docker Desktop, Chrome, and my editor are open at the same time, the fans spin up before I do, and pretty soon the laptop is running a fever…

I mostly write TypeScript, so the experience below revolves around it. If you use other languages, you can still take something from it — the principles carry over, and so do the pitfalls, haha.

How agents affect technology choices

Before coding agents became widespread, technology choices had to account for whether team members could pick up the stack and whether a senior engineer could backstop it. Now the first question is whether the language is niche, whether it’s widely used, whether there’s plenty of material out there, and whether an agent can run it independently in any environment and then prove it changed the right thing. The shift comes from a few things:

0. Tool calls & context

For an agent, the two most important things besides the model itself are tools and context. So the technologies we pick and the tools we use need to work well not just for our own development experience, but for the agent too.

For tool calls: the toolchain we choose should be faster and produce structured errors, so each call wastes less time and problems can be traced through structured logs.

For context: use simple, boring, well-documented technology that doesn’t require extra knowledge. That keeps context usage down and avoids burning context on mistakes.

Below is the execution trace of the DeepSeek harness. You can see the loop is tool call => assemble context => think. Comparing several conversations, I found the harness spends 80% of its time on tool calls, so when an agent feels slow, check whether it’s actually a project engineering problem.

1. The work has moved to cloud sandboxes

Chen Hao said in “Left Ear Listening to the Wind” that technology keeps moving toward the backend, until the frontend is just a browser or a phone. Now development itself is following that path. Meta’s personal agent Muse, released on September 8, spins up a separate virtual machine in the cloud for each user to work in. Coding agents are the same: code is written, run, and tested in a cloud sandbox, while you file requests, check previews, and hit merge from your phone. This is already the norm — sitting at your desk to develop will become a thing of the past.

2. Frameworks are starting to care about the agent development experience

Framework authors have clearly caught on. Starting with Next.js 16.2, version-matched docs are bundled into node_modules, and an AGENTS.md is generated automatically for agents to read, instead of them winging it from stale knowledge in their training data. 16.3 claims to cut dev-time memory usage by up to 90%. Vite+‘s vp run already supports running inside Codex CLI and Claude Code sandboxes. TypeScript 7 ships a dedicated --singleThreaded option for resource-constrained environments.

“Agent-friendly” is becoming a selling point alongside “fast” and “big ecosystem.”

3. Agent harnesses are evolving toward metaprogramming

The harness is the layer wrapped around the model: tools, permissions, sandbox, context, verification flow. The model decides how smart the agent is; the harness decides how much work it can get done.

The forcibly open-sourced ZCode codebase does have things worth learning from: the source of its dynamic workflow, @zcode/dynamic-workflow. It gives the model a set of TypeScript APIs, paired with analysis powered by the TypeScript compiler. The model orchestrates the flow directly in code, then hands it to a coding agent to compile, type-check, statically analyze, and execute, recovering from recorded state if it fails midway.

For TS developers, TypeScript is becoming the common language between humans, agents, and harnesses. So when choosing technology, favor strongly typed stacks that a compiler can statically check — for an agent that doesn’t mind the extra work, that’s an advantage.

New principles for technology choices

There’s an old saying in the industry: when choosing technology, pick boring technology whenever possible. It comes from Dan McKinley’s 2015 article Choose Boring Technology. He says every team gets about three “innovation tokens,” to be spent only where the product genuinely differentiates itself; everything else should use mature, boring stuff whose pitfalls have already been stepped on by others. In the AI era, that’s even more true. So when choosing technology:

1. Boring first: spend innovation tokens only on product differentiation; keep infrastructure as boring as possible.
2. Easy to get running: clone, install, dev, test — ideally those four steps get the project running and the tests passing.
3. Fast feedback: an agent compiles and tests at the end of every round, so a faster build tool means the agent finishes tasks faster too.
4. Consistent environments: dev, test, and production should behave as similarly as possible, so the agent can close the verification loop in dev/beta.
5. Verifiable results: locally, build a CLI so the agent can test logic; online, have a beta environment where it can publish a preview link and test it.
6. Friendly configuration: choose a stack with good performance and low memory usage, so you can develop and verify locally or in the cloud, and start working anytime from your phone.

Technology choices & best practices

Here’s what I’m currently using in my TypeScript full-stack projects. For each layer I’ve noted why I picked it and when to switch away. • Runtime: Bun. Fast startup and installs, so each round of agent commands runs faster. It isn’t exactly “boring” technology, but it’s genuinely good — recommended. • Package management: pnpm workspace. Fast, saves disk space, and keeps frontend and backend in one repo so the agent can see the whole project and avoid missing context. • Toolchain: Vite+. A single vp command handles dev, lint, test, and build (Vite+ Beta). It’s still in beta, so if you want stability, install Vite, Vitest, Oxlint, and Oxfmt separately. • Type checking: TypeScript 7. Rewritten in Go, full builds are typically 8 to 12 times faster. It also saves a lot of memory. • Frontend: Vite + React + TanStack Router / Query. Fast startup, few concepts, type-safe routing. Switch to Next.js or TanStack Start when you need SEO and server-side rendering. • UI: Tailwind CSS + shadcn/ui. What agents know best, and it produces the most stable interfaces. Ant Design is a great choice too. • Backend: Hono + Zod. Super fast, super lightweight, deployment-friendly, and you can write all kinds of custom middleware. My first pick for lightweight backends; for production-grade backends, Fastify is the best choice. • Database: PostgreSQL + Drizzle. PGlite for development and unit tests, real PG in CI — the same database in all three places. For small tools and single-machine deployments, SQLite is a good pick, and it deploys easily on Cloudflare. • Testing: Vitest + Playwright. Unit tests are fast, and end-to-end tests can auto-screenshot for human review. A few small details: • Oxfmt hasn’t hit 1.0 yet. Formatting output can change between versions, so pin the version in package.json — otherwise every upgrade reformats the whole repo. • Next.js is best used via OpenNext. It’s still one of the best frameworks, but it carries a lot of historical baggage. Use it when you need SEO. • PGlite is a WebAssembly build of real Postgres. npm install and it runs inside the Node process, no Docker needed — perfect for sandboxes. It’s single-connection, so CI should still run real PG as a backstop.

Lower-memory alternatives to common tools

Here are some apps I used to love but that hog memory, plus their replacements:

• VS Code / Cursor: replaced by Zed. Zed is genuinely fast, though its plugin ecosystem and themes lag behind VS Code.
• Docker Desktop: replaced by Colima. With agents around, you don’t need a GUI — CLI is better.
• iTerm2: replaced by Ghostty. Prettier, and it’s GPU-rendered.
• Raycast: replaced by popMind. Free and open source, clean and simple, and I built it myself. I’ve been happily using it for half a year — BYOK support for the latest large models, one-click selected-text translation and explanation, app search, all in one place.

Summary

When choosing technology now, since the entity doing the development has changed, what I care about first is stability, how much material exists, how complete the docs are, and whether it’s fast. Picking the right technology avoids a lot of problems. Especially for real production projects, you also need to weigh deployment cost, migration cost, and ongoing spend, among other things.

I hope this article helps, and thanks for reading.