Will Larson recently commented that “one of the interesting challenges of the AI ecosystem in 2026 is that new, effective patterns emerge faster than I can adopt them.”
He’s right, and it is a sigh of relief that someone as bright as Will feels this way too.
My X feed is flooded with breakthroughs in research, tools & exploration, and domain-specific implementations. The industrialization of knowledge leads to what philosopher Charles Taylor called the “nova effect.” There is a similar phenomenon in the AI ecosystem: an explosion of “third way” software. The better AI technology becomes, the faster we can build. While this intuitively seems to equate progress, there is a paralyzation that sets in as the AI ecosystem (including both information and technical systems) moves faster than individuals, and especially organizations, can respond to.
I think this could mean that:
Trusting personal authorities (e.g., X accounts, newsletters) over signal-gathering systems (e.g., using Grok bot to find the most relevant posts) might be the more efficient way to gather insights and keep FOMO at bay
Team topologies and workflow methodologies may have to be reinvented (rather than throwing AI at existing structures) — as Jack Dorsey recognized back in March
We will have to discern which insights move you faster in the right direction. For example, optimizing via harness engineering might be the wrong direction if a) you don’t have a financial incentive to optimize token consumption or b) you’d be better off engineering the model itself as Stripe explored
Another consideration—that has been impactful for my own agentic engineering workflow—is the opportunity to leverage existing libraries instead of depending upon generation.
LLMs brought generation into the engineering workflow. That was the breakthrough. I’d presume that the need for generation will be reduced over time as a result.
If people are able to produce software faster than ever before, then the amount of open-source tools and libraries should also be growing exponentially. If that is the case, then I can use those tools and libraries in lieu of generating my own solutions. More and more, my code becomes a wrapper that only carries the domain-specific essentials and the glue—for domain-specifics is what makes software applications something that cannot be entirely abstracted.
You can try to carefully discern the tradeoffs between which layer in the atomic hierarchy of an agentic architecture will exp, but that is costly when there is more in the wild to keep track of.
Perhaps individual engineers and organizations would do well to focus on receiving the best signals in the evolving AI ecosystem and merely gluing domain-specifics into open-source tools and libraries.
In the past, there was the concern that leveraging someone else’s code risk unpredictable migrations when that external tool/library is inflexible and/or outdated.
However, agents allow us to move faster than ever, the ability to migrate away quickly reduces this risk—and it’s possible that open-source maintenance becomes more steady since those maintainers have access to the same productive agentic tools.