2025
The dominance of AI-related topics in 2025 was undeniable, almost overwhelming.
MCP recently celebrated its first birthday, and it feels at least twice as old.
I think that’s because so much has happened in that time.
On the other hand, I still have the feeling of dealing with an immature technology.
I don’t mean (only) the frequency with which features land in copilot.
More what I have in mind is the UX/DX.
For example, how disorganized the matter of defining files with hints and preferences for agents is.
There are supposed to be some standards, but it’s hard to get your head around them.
It reminds me a bit of the browser wars that took place at the beginning of the 21st century.
From my perspective in the vendor war, the biggest losers so far are the users themselves.
The abundance of configuration options combined with the nondeterministic nature often leads to unsatisfactory results.
For example, in my agents.md file I usually start by mandating that commands executed in the shell must begin with a whitespace character,
in order to keep my shell history clean.
Unfortunately that instruction quickly falls prey to a bloated context window and — so I understand — the many configuration files don’t help.
Vendors could probably agree on some short, compressed forms of such hints.
Maybe AI could even transform a verbose human description into those predefined, standardized tips, saving precious tokens in longer tasks.
Of course this is only one of many examples. I brought it up to illustrate the situation we’re in. I understand meaning of the progress, but the road is winding and bumpy, which makes the experience at best “interesting” while I’d expect it to be “comfortable”.
For contrast, the tech stacks use at work seem to be stabilizing from a broader perspective.
Java has caught up with the competition — it has most of the “modern” features while at the same time not feeling like an experimental playground.
I’m still waiting for withers and (more) pattern matching support (guards etc) , but overall I like what we’ve gained so far.
I had a chance to use some of it, even though this year I mostly worked on frontend.
How was that possible? I benefited from the growing popularity of html-over-the-wire.
I had the opportunity to use a stack of java + spring + thymeleaf + htmx.
I found the experience very interesting and satisfying, although not without some issues.
The first point is that I wouldn’t recommend this approach for very interactive applications.
The popularity of modern JavaScript libraries and frameworks didn’t happen for nothing.
Without client-side reactivity, for more complex scenarios business logic quickly leaks into controllers.
However, that’s a matter of choosing the right tool for the problem, not the technology or even the architecture itself.
The project I worked on was somewhere in between.
On one hand it didn’t have a lot of frontend interactivity.
On the other hand, when I gave up the simplicity of full page reloads in favor of a Single Page Application experience,
the controller code grew significantly more complex.
Working on that project made me realize that this stack (and even the architecture) deserves some loose set of patterns similar to the redux-style ducks.
I mean here things like endpoint granularity, the way form state is passed, etc.
Maybe this is characteristic of htmx as the simplest variant of html-over-the-wire,
and more advanced tools like HotWire or Phoenix LiveView
may have this built in — I hope to find out in 2026. 🤓
Back to the stack’s problems, mixing htmx with Thymeleaf was a real pain.
Fortunately syntax issues were partially mitigated by using a
invaluable integration library.
Hats off to the author, great job.
As I mentioned earlier, in 2025 I did a lot of frontend work, so there was also plenty of Next.js. The technology is starting to stabilize, although the recent react2shell situation probably shook community trust a bit.
I think that happened at a very unfortunate moment, because for some time I’ve been seeing a growing wave of adopters moving to TanStack. I don’t know how widespread full migration is, but I myself had the chance to use tanstack-form in its React flavor.
The library seems well-thought, especially regarding TypeScript integration. However, I have substantial doubts around handling collections. Using the index as a key feels like a controversial choice that doesn’t fit with React’s way. I assume it stems from the library’s generic nature, as React is only one of the supported flavors. I understand the authors’ decision, but as a user I have mixed feelings. From what I remember, this caused real problems when modifying collections. Maybe I lacked knowledge (despite reading the docs) and did it wrong somehow. Given how much fashion and trends influence developers’ choices, I think it still has good chances to gain popularity.
I also have some observations regarding DX.
First, the library quite strongly enforces a particular way of writing code — separating component code from the library is problematic, especially when at the same time trying to extract dedicated components (e.g. for layers, reusable components, etc.). In other words, it leaks into the implementation and introduces coupling.
Second, strong integration with TypeScript is not free — let’s take an example. One way to access object fields is using field name selectors, like:
<form.Field name="people" mode="array">where people is an object field and its compatibility with the model is checked at the type level (!).
In the optimistic case the IDE nicely suggests possible field selectors.
The problem arises when you start changing the model.
I experienced both:
- false-positives on selectors of subcomponents when I had errors in the model, and
- the opposite — sometimes I had to restart the IDE and refresh the cache when something remained highlighted as error
Moreover, it generated a noticeable performance overhead.
I don’t know how much of it was the continuous work of the tsc compiler, because the other bottleneck was Copilot.
The fact that a MacBook with an M4 has trouble with the environment made me think. I realize this is a conjunction of multiple factors. Nevertheless, it’s somewhat at odds with the pursuit of simplicity and efficiency promoted this year by DHH in his omarchy project. OS and editor are theoretically separable topics, but first of all I’m thinking border. Besides that, there can be synergies between editor and OS in certain scenarios.
Currently, both at work and for personal projects I still use Macs with Nix and home-manager, but the experiences mentioned above make me reconsider that status quo. Regarding editors, in personal projects I’m testing Zed with vim mode, which seems like an interesting compromise. As for the OS, I’ve had long stretches using Arch and its forks in the past. Moving to a Mac was caused by fatigue with instability and problematic rollbacks of buggy updates.
Back then I didn’t know Nix, and I liked Arch for its simplicity. I follow omarchy’s development with interest, but for full happiness I miss stronger security guarantees there. I know there are Arch forks that offer some immutability (SteamOS among them) and that there’s an initiative for reproducible builds.
However, I don’t see an obvious winner for myself for now. Hobby-wise I test NixOS in a VM. A loose inspiration here was Mitchell Hashimoto’s approach, and a potential future complement could be omanix.
Unfortunately the aspects mentioned above, as well as objective obstacles, pulled me away from exploring other, new areas and even from blogging itself.
2026
The biggest question for everyone is probably what will change in the context of AI. The way we work evolves almost constantly. Building new compute centers has caused memory prices to spike in the last quarter of 2025, much like GPU prices did at the height of the mining boom.
On the other hand, you hear a lot about the whole AI topic overheating. The question is whether this year will bring more stabilization or, conversely, whether a new AI black swan will appear.
As I write this, my guiding thought for 2026 is to seek balance in growth, by exploring new areas interleaved with consolidating knowledge and my toolbelt. As I mentioned at the end of the 2025 summary, movement in tooling (especially omarchy) inspired me. I think DHH (again) diagnosed the problem well and proposed an intriguing direction of solutions. The enormous dynamism of changes in the way we work creates an obvious need for order. Chasing every new AI tool may cause losing sight of the ultimate goal. To be honest, it’s not a completely new phenomenon in our industry, but the situation feels unprecedented. New tools should serve us, not the other way around. It’s astonishing how easily we are willing to sacrifice important aspects like functionality, simplicity, security or performance, dazzled by ever-new agent capabilities.
Against that background, putting the developer back at the center of the production process seems to me a justified course correction.
A funny side effect could be the unexpected coming true of the long-mocked “year of linux”, like Bilbo leaving the Shire. With that optimistic note I wish myself and you a pleasantly surprising 2026.
So long 🖖