I'd skip GraphQL for most applications. It's not that GraphQL is bad — it solves real problems with over-fetching and under-fetching — but the backend complexity it introduces (N+1 queries, field-level authorization, resolver performance) is rarely worth the frontend benefits for applications that aren't Facebook-scale. A well-designed REST API with OpenAPI-generated types gives you most of the frontend benefits (typed responses, code generation) without the backend complexity, and for the cases where you genuinely need flexible querying, a BFF (backend-for-frontend) layer is simpler than a full GraphQL deployment. GraphQL is the right choice for a specific category of applications (many clients with different data needs, complex nested data, mobile clients where payload size matters enormously), but that category is smaller than GraphQL's popularity suggests.

I'd skip microservices for teams smaller than, say, fifty engineers. The operational complexity of microservices — service discovery, distributed tracing, inter-service authentication, network failure handling — is a fixed cost that doesn't pay off until you have enough services and enough engineers to amortize it. A well-structured monolith with clear module boundaries gives you most of the development benefits (independent teams, deployable units) without the operational overhead, and it's dramatically easier to debug. The default should be a monolith; microservices should be a deliberate choice made when the monolith is genuinely holding you back, not a preemptive architecture decision made because "we might need to scale someday."

I'd use serverless carefully. The promise is real — no infrastructure to manage, automatic scaling, pay-per-use pricing — but the trade-offs are significant. Cold starts add latency that's invisible in testing and noticeable in production. The execution model (stateless functions with limited execution time) doesn't fit all workloads, and working around it produces awkward architectures. Vendor lock-in is real, and the cost model that's cheap at low scale can become expensive at high scale in ways that are hard to predict. Serverless is excellent for event-driven workloads, sporadic traffic patterns, and prototypes; it's less excellent for steady-state services with predictable traffic, where a traditional server or container is simpler and cheaper.

I'd use AI code generation carefully. The tools are genuinely useful — they're great for boilerplate, for API patterns you use infrequently, for getting started on a new file — but they're also genuinely dangerous when used without understanding. Generated code that looks right but is subtly wrong is worse than no code at all, because it passes review (it looks right) and fails in production (it isn't right). The rule I use is: never accept generated code I couldn't have written myself. If I can't evaluate whether the code is correct, I don't use it, because I'm not qualified to maintain it. AI code generation is a productivity multiplier for engineers who can already do the work; it's a liability for engineers who can't, because it lets them ship code they don't understand.

I'd bet on TypeScript. The trajectory is clear — the JavaScript ecosystem has consolidated around TypeScript as the default, and the tooling has matured to the point where the cost of adoption is low and the benefit is substantial. If you're starting a new JavaScript project in 2026 without TypeScript, you're taking on a burden that will compound over the life of the project. I'd bet on edge computing for the specific category of applications where latency matters — the edge is where the network is fastest, and pushing computation to the edge is a structural advantage that can't be matched by origin-server optimization. I'd bet on observability as a first-class concern — the tools are mature enough that there's no excuse for unobservable systems, and the operational benefits of being able to see what's happening in production are too large to defer.

I'd also bet on boring technology. PostgreSQL, React, Docker, Git — these aren't exciting, but they're proven, they have communities that will be around for decades, and they solve the problems they solve well enough that switching costs will keep you on them for a long time. The excitement of new technology is real, and it's valuable for pushing the field forward, but the excitement is a poor basis for production decisions. Bet on boring for the core of your stack, and reserve the exciting technology for the edges where the risk of a wrong bet is contained. That balance — boring core, exciting edges — is the one that has served me best, and it's the one I'd recommend to anyone building a system they expect to maintain for more than a year.