LLMs Are Making Boring Tech Even Harder to Beat
The "boring technology" argument has always been straightforward: mature, widely adopted tools come with mountains of accumulated knowledge. Tutorials, Stack Overflow threads, and decades of blog posts make troubleshooting and learning significantly easier. With the rise of LLMs, that calculus has shifted even further in favor of the established tools.
LLMs are trained on massive corpuses of text. The more content exists about a technology, the better the model understands it. Boring technologies have decades of material—reference manuals, examples, academic papers, and forum discussions—all of which becomes training data. Shiny new technologies, however, have comparatively sparse coverage. Their documentation is thinner, and the community knowledge is still forming. The result is that LLMs are disproportionately better at helping with old, boring systems than new, exciting ones.
The LaTeX Case Study
LaTeX is a textbook example. It has been the standard for academic writing since the 1980s and remains widely used today. Its age is a feature in this context: nearly every conceivable error, customization, or package question has been asked and answered somewhere. LLMs have absorbed all of that. They can recall obscure symbol names, explain error messages, and generate complex boilerplate with ease.
This erodes much of the appeal of newer typesetting systems like Typst. For all their modern design and clean syntax, they simply don't have the same wealth of prior art for LLMs to draw upon. Things that would require significant manual research in a new system can often be solved in seconds with LaTeX and an LLM, whether it is used standalone or through integrated helpers like Overleaf's built-in AI or VSCode plugins.
The "too big, too full of cruft" criticism of boring technology also loses some force. LLMs are good at cutting through the learning curve. They can guide you to exactly the package or command you need without requiring you to digest decades of accumulated docs. That apparent cruft is less of a liability when the assistant you're working with knows how to navigate it.
Where LLMs Actually Help
A few specific LaTeX tasks have benefited particularly from LLM assistance in practice:
- Finding symbols and math syntax — describing a symbol or asking for an equation in natural language and getting the correct LaTeX back has all but replaced reference material scanning.
- Debugging errors — pasting a code snippet and the accompanying error message into a standalone LLM is a practical way to resolve issues without serious sleuthing, though the majority of LaTeX error messages are clear enough on their own.
- Generating TikZ diagrams — the hardest part of making diagrams is often just getting started with the right element names. Asking an LLM for an initial version and tweaking it manually is a solid workflow, and you can go one step further by having it produce a Python generator for repetitive diagrams.
- Creating tables — generating structured tables from other data formats or screenshots is straightforward for modern LLMs.
- Formatting questions — quick answers on margins, spacing, and other typesetting details are easy to extract from an LLM.
This doesn't mean Typst or other modern systems aren't impressive; they are. But for someone evaluating the total-effort tradeoff, the combination of a mature tool and a capable AI assistant is hard to beat. The question is no longer just about the technology itself—it's about everything that has been written about it.
| [1] | When it comes to scripting, I generally prefer sticking to real programming languages anyway. If there's anything non-trivial to auto-generate I wouldn't use a LaTeX macro, but would write a Python program to generate whatever I need and embed it into the document with something like \input{}. Typst's scripting system may be marketed as "clean and powerful", but why learn yet another scripting language? |



