Every year-end post risks either overselling hype or underselling real change. Looking back at this year across every project we shipped, a few things clearly changed how we actually build software, and a few loudly discussed things changed less than the noise around them suggested. This is our honest attempt to sort one pile from the other, written the way we'd want to read it if we were a client trying to figure out what actually matters for how their own team builds.
What genuinely changed
Agentic AI tooling moved from assisting individual lines to executing well-specified multi-file tasks, and the bottleneck shifted from writing code to writing clear specifications and maintaining strong test coverage. This wasn't a single dramatic leap, it was a steady accumulation of smaller improvements across the year that added up to a qualitatively different way of working by the time we hit the fourth quarter. Teams that invested early in clean architecture and thorough tests are extracting real, compounding value from agentic tools now, and the gap between those teams and teams that didn't is widening rather than narrowing.
Tailwind v4's new engine and edge-first architecture becoming our default both delivered real, measurable improvements, faster builds and lower latency respectively, rather than just being trend-following. Build times on our larger projects dropped meaningfully enough that it changed the day-to-day feel of iterating on styling, and edge deployment stopped being a special-case optimization and became simply where new projects start unless there's a specific reason not to. Neither of these was a bet on hype; both were adoptions of infrastructure that had matured past the point where the old approach was still defensible on its own merits.
- Agentic AI tooling shifted the bottleneck from writing code to writing clear specifications and maintaining strong test coverage.
- Tailwind v4's engine and edge-first architecture both delivered measurable, not just fashionable, improvements.
- The gap between teams with strong engineering fundamentals and teams without widened as AI tooling matured.
- Client conversations increasingly start from "how do we use this well" rather than "should we use this at all."
What didn't live up to the noise
Not everything lived up to its hype; a couple of tools we piloted this year quietly got shelved because the integration cost never stopped outweighing the benefit for our actual client work. We won't name names, most of these weren't bad products, they were solutions to problems slightly different from the ones our clients actually have, and the marketing around them was better than the fit. The pattern we noticed across all of them: tools that promised to replace an entire category of engineering decision-making tended to disappoint, while tools that promised to remove a specific, well-defined piece of friction tended to deliver. Ambition that outran the actual problem being solved was the common thread in every shelved pilot.
We also want to flag a category that didn't change as much as conversations outside our own team suggested it would: the fundamentals of good software architecture. Clean boundaries between modules, thoughtful data modeling, and honest tests mattered exactly as much this year as they did five years ago, arguably more, since these are precisely the properties that determine whether an AI agent working in your codebase produces something maintainable or something that merely compiles. We spent a fair amount of time this year explaining to clients that better tooling is not a substitute for these fundamentals, it's a multiplier on them, and a multiplier on a weak foundation doesn't produce a strong result.
What we're carrying into next year
The through-line across every genuine improvement this year was the same: better tooling didn't remove the need for engineering judgment, it moved where that judgment gets applied. Reviewers now spend their attention verifying that an agent's approach matches its stated plan rather than typing out boilerplate themselves. Architects spend more time thinking about how a system's boundaries will hold up when an autonomous agent is working inside them, rather than assuming only careful humans will ever touch that code. None of this is a smaller job than before. It's a differently shaped one.
We're also carrying forward a healthy skepticism toward anything pitched as a wholesale replacement for engineering judgment rather than an amplifier of it. Every genuinely useful tool we adopted this year made a specific, well-understood problem faster to solve. Every tool that promised to make engineering judgment itself unnecessary ended up disappointing whoever bought that pitch. We expect that pattern to hold next year too, and we're staying deliberately unimpressed by any pitch that doesn't respect it.
The honest bottom line
Heading into next year, the practices we're carrying forward are the ones that held up under real client deadlines, not the ones that looked best in a demo. That's always been the actual bar, AI-assisted or not, and it's worth restating plainly because it's easy to lose track of in a year with this much genuine change happening around us. The teams and clients who did best this year weren't the ones who adopted every new tool first, they were the ones who kept their fundamentals sound while adopting the tools that actually solved a problem they had. We expect that to remain true regardless of what next year's headline technology turns out to be.
It's worth noting how much the tenor of client conversations changed over the course of the year, since that shift is itself a useful signal about how normalized these practices have become. In January, a client asking about AI-assisted development was usually asking a somewhat theoretical question, curious whether it was worth exploring, cautious about handing meaningful work to a tool they didn't yet trust. By the fourth quarter, the more common question wasn't whether to use agentic tooling at all, it was how to structure their own internal processes, their own ticket-writing conventions, their own test coverage standards, to get more value out of tools they'd already decided to adopt. That's a genuinely different conversation, and it required us to develop a different kind of advice than we were giving at the start of the year.
We also found ourselves talking clients out of over-investing in the tooling itself relative to their fundamentals more than once. More than one client came to us wanting to evaluate several competing agentic coding platforms in detail, when the more valuable conversation, once we dug into their actual situation, turned out to be about the state of their test suite or the clarity of their ticket templates. The tooling landscape matured enough this year that the marginal choice between reasonably capable competing platforms mattered far less than whether the team using any of them had the underlying engineering discipline to get value out of it.
We adjusted how we think about hiring and team composition somewhat this year, though less dramatically than some industry commentary suggested we should. We didn't reduce headcount or restructure roles wholesale. What did change was a modest shift in what we screen for during hiring: the ability to write a clear, unambiguous specification and to review someone else's work critically became skills we probe for more directly in interviews than we used to, alongside the traditional emphasis on being able to write good code from scratch. Those two skill sets overlap substantially with what makes someone a good engineer under any circumstance, but the relative weight shifted noticeably.
We also noticed that engineers who came up through code review-heavy environments, open source contributors used to having their pull requests scrutinized carefully by strangers, adapted to reviewing agent-generated code faster than engineers whose prior experience was mostly solo work reviewed lightly, if at all. That's an interesting enough pattern that we've started weighting open source or heavily-reviewed collaborative experience somewhat more in hiring conversations than we did a couple of years ago, treating it as a reasonably good proxy for the specific reviewing skill this new way of working leans on most heavily.
We're resisting the temptation, common to year-end posts like this one, to close with a confident list of predictions for next year. Most predictions of this kind age poorly, and we'd rather be honest about the genuine uncertainty in how quickly any given tool or practice will mature than manufacture false confidence for the sake of a satisfying ending. What we will say is narrower and, we think, more useful: whatever changes next year, the teams that do well with it will be the ones whose fundamentals, tests, clear specifications, thoughtful architecture, were already sound before the new tool arrived, because every genuine improvement we adopted this year amplified strength that was already there rather than creating it from nothing.
That's a less exciting note to end on than a bold prediction, but it's the one we actually believe, and it's consistent with essentially everything else in this retrospective. We'd rather be right about something modest than confidently wrong about something dramatic, and we'll keep writing next year's version of this post with the same standard in mind.