Trend pieces are usually a list of nouns with confident adjectives attached. I want to do something narrower: for each thing actually changing my day-to-day work, say what changed, whether it is durable, and what I did about it. Skip that, and it's just content.
I'll flag upfront where I'm confident versus guessing. There's a real difference between "this is already true in my own work" and "this seems likely from where things are heading," and blurring the two is how trend pieces age badly.
Agentic coding tools became the default interface, not a novelty
This is not a prediction, it is a description of what already happened. A year ago, using an AI coding assistant well was a differentiator. Now not using one is the outlier, at least among the engineers I work alongside.
What actually changed is the unit of delegation. It used to be autocomplete: finish this line. Now it is a scoped task: implement this function against this test, refactor this module to this interface, find and fix the bug matching this stack trace. The difference in what you can hand off is large.
What I did: I stopped treating it as autocomplete-plus and started treating it as a colleague I brief and then review. That meant writing sharper specifications, defining "done" before starting, and building the habit of reading every diff completely rather than skimming. More detail here if you want the concrete workflow.
Durability: high. This is not a fad that reverses. The tools will keep changing shape, the shift in where your attention goes will not.
The job's centre of gravity moved from writing to specifying and verifying
Related to the above but distinct enough to name separately, because it changes what you should practise.
Writing code fast used to be the scarce skill. It no longer is. What is scarce now is being able to state precisely what should be built, and being able to tell quickly whether what came back is actually correct. I wrote a full piece on this because it deserves more than a paragraph: the old developer versus new developer.
Durability: high, for the same reason as above. It is a consequence of production costs falling, not a fashion.
MCP became the integration layer for tools, not just AI
Model Context Protocol started as "how do I give an AI assistant access to my database." It is turning into something closer to a standard way for tools to expose capabilities to any caller, AI or not.
The practical effect: instead of every integration being a bespoke API client, more tools are showing up with an MCP server already built. Appwrite has one. So does GitHub, Vercel, and a growing list of platforms I actually use. Wiring up access used to be an afternoon of reading docs. Now it is often a config entry.
What I did: used it to connect Claude Code directly to project infrastructure rather than pasting IDs and error messages back and forth by hand. Wrote up how.
Durability: medium-high. The protocol itself might not be the one that wins long term, but "tools expose a standard interface for agents to call" is the right shape and something will fill it even if the name changes.
Server-first React is no longer optional knowledge
React Server Components moved from "the new Next.js thing" to the default mental model for how a lot of new code gets structured. Client components are now something you opt into for interactivity, not the default for everything.
The trend under the trend: the industry is slowly correcting the SPA-everything era. Shipping a fully client-rendered app for content that could have been server-rendered is now a choice you have to justify, not the default nobody questions.
What I did: treat "does this need to run on the client" as a real question for every component, instead of reaching for "use client" out of habit. Longer take here.
Durability: high for the architectural idea, medium for the specific APIs, which are still moving.
Performance budgets became a planning input, not a post-launch cleanup
More teams are setting a size or timing budget for a page before building it, the way you'd set a database schema before writing queries against it. This used to be something you did during a "performance sprint" six months after launch, if ever.
Part of this is Core Web Vitals maturing into something product and SEO teams actually watch. Part of it is that AI-assisted development makes it easier to add dependencies faster than before, which makes budgets more necessary, not less.
Durability: medium. This one is closer to a discipline than an inevitability, it depends on teams actually enforcing it. I wrote about the mechanics here.
The model landscape keeps moving, and that's the point, not a specific pick
Here I want to be honest rather than confident. New models keep shipping, from Anthropic and everyone else, and if you're reading this expecting a ranked list of which one is best, that list would be stale within weeks of being written, possibly before you finish reading it.
What is actually durable is not any particular model, it's the fact that the effort-vs-capability tradeoff keeps improving, and that picking the right model and effort level for a task is now a real skill, not a settled default. I wrote about how I think about that tradeoff concretely, model by effort level, here, and I'd rather point you at the framework than at today's leaderboard.
Durability: the framework, high. Any specific model comparison, low, by design of how fast this space moves.
What I'm consciously not chasing
A trends piece is more useful if it says what to ignore, so:
Rebuilding on whatever framework has momentum this quarter. Momentum is not the same as advantage for your specific product. Most rewrites driven by "everyone's moving to X" cost more than they returned, in my experience and in what I've watched other teams go through.
Benchmarks as a proxy for "which tool should I use." Benchmarks measure benchmarks. Your task is not the benchmark. Try the tool on your actual work for a week before believing a leaderboard.
Treating agent output as a substitute for code review discipline. The single biggest risk I see teams take on right now is skipping review because the code "came from AI so it's probably fine." It is not more trustworthy for being generated quickly. If anything it deserves more scrutiny, not less, because nobody on your team has the mental model for how it was written.
The actual takeaway
Almost none of this is about a specific tool. It is about where the leverage moved: toward specification, verification, architecture, and judgment about what not to build. The tools implementing that shift will keep changing shape through 2026 and past it. The shift itself is the trend worth tracking, and it is the one I'd bet on being true a year from now, unlike any specific product name in this piece.
- #Trends
- #AI
- #Full Stack
- #Engineering
- #React