The year ahead

It’s prediction season! On this newsletter, I like to (somewhat inconsistently) write a post looking ahead to the coming year, setting out what I think will be meaningful directions. You can read the 2023 and 2024 versions from the archive.

In past years, I’ve focused on broader conceptual areas. They have developed in some ways - simulated data is very much a thing now, and there’s been a push for small language model adoption in enterprises. But this year I want to zoom in on a few more concrete themes that will, hopefully, guide what what I post here throughout the coming months.

Two quick sidebars - first, I overhauled the look and feel of the newsletter! The old setup was starting to feel restrictive as my writing expanded to cover not just digital platforms, but also genAI and software development as it relates to the media. I’m hoping this redesign matches that broader remit.

Second, if you’re in the mood to go deep on media predictions, I took all 210 of Nieman Lab’s prediction posts for 2026 and put them in a NotebookLM project. Think of it as a little interactive index and synthesis layer over the whole set.

With that, I have three themes in mind for this year:

At some point in the past year, coding with LLMs shifted from promising but frustrating to genuinely useful for a whole class of work - quickly spinning up tools, prototypes, and one-off utilities that would have taken half a day or more to build. Simon Willison has thoroughly demonstrated the power of this development pattern; his collection of largely LLM-assisted projects now sits at 169 tools - OCR helpers, JSON diffing tools, Bluesky timeline exporters, image croppers.

But the productivity gains aren’t limited to personal projects. Boris Cherny, who created Claude Code at Anthropic, recently shared that over the past month he’s landed 259 PRs, with every single line written by Claude. A year ago, Claude struggled to generate bash commands. Now it’s writing production code at a pace that would be unsustainable for any individual human.

My own experience sits somewhere between these poles. I’ve found LLM-assisted coding most useful for diagnostic work: quick dashboards to visualize data pipelines mid-analysis, high-fidelity prototypes to test research ideas, and helper scripts to navigate thorny config issues (e.g., AWS setup). The common thread is that these are all things I could have built before, but wouldn’t have, because the friction-to-value ratio was too high.

Taken to its extreme, the ability to build things with code on demand entirely liquifies our experience of the web. Google’s Disco browser experiment offers a glimpse of this kind of entirely malleable interface - “GenTabs” that transform whatever tabs you have open into custom, interactive applications. The distance between “I have this information” and “I have a useful view of this information” is collapsing.

On one level, this is liberating - it allows you to build alternative visualizations for data, to reorganize information into new structures, to switch modalities entirely. But flexibility without constraint has its own failure modes. In Hollywood, the shift to digital VFX created a similar dynamic: When everything can be changed in post-production, everything getschanged in post-production. A 2022 investigation by Defector documented the consequences - exhausted artists, endless revision cycles, and the paradox that more capability led to worse outcomes. The freedom to revise indefinitely becomes a trap.

One more thought here: The malleability runs deeper than the flashy vibe coding demos suggest. Consider a traditional data or ML pipeline, where adding or changing steps used to require expensive engineering time and careful coordination. Now an LLM can build out transformations, train models, and iterate on approaches with minimal friction. The marginal cost of an exploratory pipeline - or even a robust, production-ready one - is approaching zero. That’s a quiet transformation, but potentially a more significant one than any individual tool.

It’s clearly useful to inject outside information into LLMs. Web search makes ChatGPT a viable replacement for Google (at least for many queries). NotebookLM has seen substantial adoption by students, researchers, and journalists looking to synthesize large document sets. In our own research, we found that NotebookLM performs better than comparable chatbot applications at staying grounded in its source material.

But in that same work, we also found - as others have in different contexts - that RAG-based systems struggle to accurately interpret underlying documents. Even with accurate retrieval, the generation step can produce claims that conflict with what was retrieved. This matters enormously for work that depends on careful attribution. When a journalist embeds an opinion inside a quote, attributing it to a political figure rather than stating it as fact, that distinction is load-bearing. A system that flattens that provenance chain is worse than useless for certain kinds of knowledge work.

This points to a deeper issue: RAG, as currently implemented, is more a clever hack than a principled solution. The conceptual model doesn’t align with how real-world document understanding actually works. RAG breaks documents into chunks and runs semantic search over those chunks. This assumes the chunks are relatively homogenous in quality and structure - which might hold for a collection of technical documentation, where each section stands reasonably well on its own.

But this isn’t how investigative journalists read documents. They care about structure. They care about repeated references or conspicuous omissions. They care about non-obvious connections across a corpus. Chunking documents into text blobs annihilates all of this nuance, and with it any potential for LLMs as serious investigative tools. I’d wager there are similar obstacles in other domains where the relationship between documents matters as much as the content within them.

What we need are new ways to structure knowledge before passing it to LLMs - structures that acknowledge how knowledge work actually happens. That means thinking about provenance. It means accounting for document heterogeneity: A leaked email is not the same as a press release is not the same as a deposition transcript, even if they contain similar words. And it means designing retrieval systems that can surface relationships and patterns, not just semantically similar passages. This is a research problem, but it’s also a design problem - one that will shape whether LLMs become genuinely useful for complex knowledge work or remain stuck at the level of sophisticated summarizers.

This last theme is less explicitly about generative AI than the previous two, though the threads connect. I’ve written this year about small language models and a “tiny tools” framework for human-centered technology in journalism. And I obviously believe in vibe coding purpose-built tools for personal or organizational use. But these are only facets of a broader shift that I think we’re in the middle of, one that extends well beyond AI.

The shift is about control. We need tools that we actually own and can shape to our needs, whether that’s an AI model, a database, or the scheduling system at your doctor’s office. Somewhere along the way, the software industry cut too many people out of using the computer in any meaningful sense.

But all of a sudden, we’re on the cusp of having solutions to many of the constraints of building and distributing software. Ink & Switch has been doing some of the clearest thinking here, articulating a vision of malleable software where adaptation happens at the point of use rather than through distant engineering teams. The Resonant Computing manifesto frames similar concerns in terms of human flourishing, arguing for software that is private and adaptable.

There are a lot of elements at play here: local-first data architectures that keep your information on your devices, AI assistants that can help non-programmers modify their tools, malleable document formats that blend content and computation. None of these solve the whole problem individually, but together they suggest that a different relationship with software is becoming technically feasible.

What I hope for, broadly, is that the computer becomes a tool again - something we can all use without paying rent to a platform, or surrendering our personal information, or implicitly subscribing to a political philosophy we didn’t choose. The pieces are starting to come together.

The common thread across these three themes is a shift in where capability lives. Malleability moves the ability to build software closer to the people who need it. Better knowledge structures would make AI systems respect workflows that already exist, rather than flattening them. Local software puts ownership back in users’ hands. These are the directions I find myself most interested in, and the ones I’ll be writing about here throughout the year.