The Tools AI Won't Reach For: Six Pieces of Software the Default Skips

The Hugo Problem

Ask an AI to build you a website, and you will get React. You will get Next dot js, Vercel for hosting, probably a Postgres database thrown in for good measure. Mention Hugo, the static site generator, and the same AI will happily build you the simpler thing instead. It knew about Hugo the whole time. It just did not lead with it.

Here is the part that takes a while to get right, and it is worth being precise about. The blind spots are not uniform. It is not simply that an AI ignores every tool without a marketing budget. Some humble tools have broken all the way through. SQLite is now often the first database an AI reaches for, sometimes even when something heavier would genuinely fit the job better. The fast Python installer called uv went from unknown to default suggestion in roughly a year. The models learn. The defaults drift.

So the useful skill is not collecting obscure software for its own sake. It is knowing precisely where the defaults are still wrong. Where the AI still reaches for the heavy, famous, expensive option because that is what the training text is saturated with, while a lighter thing has been sitting right there the entire time.

What follows is six of those places. Six tools an AI will build for you the moment you say the name, but will rarely suggest on its own.

htmx Refuses to Build the SPA

In twenty twenty, a computer science instructor at Montana State University named Carson Gross released version one of htmx. He had been building toward it for years under an earlier name, intercooler dot js. The pitch was small and almost suspiciously boring. It was a JavaScript library that lets ordinary HTML elements make HTTP requests and swap in fragments of HTML, without you writing any JavaScript yourself.

The consequence was not boring at all. If your server returns HTML, you do not need a single-page application. You do not need React. You do not need a client-side state management library, you do not need a ninety-second build step, you do not need to ship megabytes of JavaScript to a browser that already knows, natively, how to render HTML and submit forms.

Carson called the underlying idea hypermedia as the engine of application state. The acronym is HATEOAS, and it is genuinely painful to say out loud. It comes from Roy Fielding's doctoral dissertation on REST, written in the year two thousand. The web was originally designed to work this way. Frontend frameworks then spent fifteen years convincing everyone it should not.

htmx now runs in production at the United States Air Force, on parts of Bandcamp, on selected pages of GitHub. The community has a running joke about being correct by being twenty years late. Ask an AI to build a typical forms-and-records web app and you will get Next dot js by default. Say the word htmx, and the same model will rebuild that app in a fraction of the code with no build pipeline at all. The tool listens for the noun. You have to know the noun.

DuckDB and the Query That Runs Next to the Data

In Amsterdam there is a research institute called CWI. It is where Guido van Rossum invented Python in nineteen eighty-nine. Decades later, two researchers at that same institute, Mark Raasveldt and Hannes Mühleisen, asked a pointed question. The world had SQLite, a tiny database that runs inside other programs for transactional work. Why was there no equivalent for analytical work? No embedded engine for the heavy aggregations, the group-bys, the joins across millions of rows?

So they built one and called it DuckDB. It compiles to a small binary. It runs inside your Python process or your Node process, with no server to manage. It executes columnar analytical queries at speeds that genuinely compete with cloud data warehouses costing thousands of dollars a month. It reads Parquet, CSV, JSON, and Excel files directly, from local disk or straight off an S3 bucket, without importing them first. The first release was in twenty nineteen.

The reflex for any AI asked about data analysis is to suggest pandas. Pandas is fine, right up until your data does not fit in memory, or an aggregation starts taking six minutes, or you simply want to write SQL you already know instead of memorizing the difference between two nearly identical indexing operators. DuckDB does the same work in seconds, with standard SQL, and the integration is a single line of code.

The deeper point, the one no cloud vendor will volunteer, is that an enormous amount of what gets sold as production database infrastructure is actually analytical work. And analytical work usually wants to run right next to the data, inside your process, not across a network connection to a rented server. That story costs vendors money. So the AI, trained largely on what those vendors and their consultants publish, will not tell it to you either.

NATS: Messaging Without the Cathedral

When two services in a system need to talk to each other without waiting on each other, you reach for a message broker. Ask an AI which one, and you will almost certainly get Kafka. Possibly RabbitMQ. Both are serious, capable systems. Both are also cathedrals. Kafka traditionally wanted a coordination service alongside it, a Java virtual machine, real memory, real operational attention. For a huge number of projects, that is like renting a shipping port to mail a postcard.

There is a quieter option named NATS. It was created by Derek Collison, an engineer with deep history in this exact domain. He had built messaging systems on Wall Street, including the one many trading floors ran on for years. He knew precisely how heavy this software usually gets. NATS was his argument that it did not have to.

The NATS server is a single binary, around twenty megabytes, that starts in a fraction of a second and needs almost no configuration. It runs comfortably on a fat server, and it runs comfortably on a Raspberry Pi at the edge of a network. The name officially stands for Neural Autonomic Transport System, though almost nobody says that out loud. It does publish and subscribe, it does request and reply, it does load-balanced work queues, and with an added layer called JetStream it does durable, replayable streams when you actually need them.

It is not a niche curiosity. Tesla uses it. PayPal uses it. Walmart uses it. It is a project of the Cloud Native Computing Foundation. And yet ask for a messaging system and the default answer remains the heaviest one in the room. Say NATS, and the AI will wire up the lightweight version of the same idea, the one you can actually run yourself without a dedicated operations team.

Typst: Two Theses Against LaTeX

If you want a properly typeset document, a paper, a report, a book with real footnotes and a real index, the traditional answer is LaTeX. LaTeX produces beautiful output. It has also been making people miserable since the nineteen eighties. The installation is enormous. Large documents compile slowly. The error messages read like riddles from a hostile oracle. Any real customization means learning an arcane macro language that fights you the whole way.

In twenty nineteen, two German developers, Laurenz Mädje and Martin Haug, decided to write a replacement, in their own words, just for fun. The fun got serious. By twenty twenty-two they had each turned it into a master's thesis at the Technical University of Berlin, one on the language design, one on fast incremental compilation. They called the result Typst. The first public beta arrived in twenty twenty-three.

Typst keeps the parts of LaTeX that earned the loyalty. It uses the same line-breaking mathematics that Donald Knuth designed for TeX, so the paragraphs are just as beautifully balanced. But the markup reads like Markdown instead of a thicket of backslashes and curly braces. The whole compiler is one small binary that needs no administrator privileges. Packages download the first time you use them and then cache. And it compiles in milliseconds, not seconds, so you get a live preview as you type.

It is already doing serious work. The Indian financial firm Zerodha switched its document pipeline to Typst and reported generating roughly one and a half million PDF files in twenty-five minutes. Ask an AI to help you produce a polished PDF and it will reach for LaTeX, or it will suggest gluing together some HTML-to-PDF browser engine. Say Typst, and it will write you something legible that compiles before you have lifted your hands from the keyboard.

just: A Task Runner, Nothing More

Every project past a certain size needs saved commands. Run the tests. Build the docs. Deploy to staging. The traditional tool for this is Make, which was written in nineteen seventy-six at Bell Labs to compile C programs. Make carries forty-eight years of accumulated design decisions, and one of them is genuinely notorious. Make requires tab characters for indentation. If you use spaces by accident, it fails, and it fails without telling you why. That single decision has cost the software industry an almost unmeasurable number of debugging hours.

In twenty sixteen, a programmer named Casey Rodarmor released a tool called just. It looks like a Makefile. It reads like a Makefile. It does not care whether you typed tabs or spaces. It has no hidden implicit rules quietly trying to compile things behind your back. It does not attempt to be a build system at all. It is a task runner, and only a task runner. That restraint is the entire point.

You write a file called a justfile. You list your commands in it. You type "just test", or "just deploy", and the matching recipe runs. There is almost nothing else to learn, which is exactly what you want from the least interesting part of your toolkit.

Casey Rodarmor later went on to create Bitcoin ordinals, in twenty twenty-three, which depending on your view of cryptocurrency is either a strong endorsement or a gentle warning. Either way, the man ships finished software. Ask an AI to set up project commands and you will get a Makefile, or worse, a folder full of loose shell scripts named build and deploy and run. Say "use just", and you get one clean file anyone on the project can read at a glance.

Pocketbase: Your Backend Is One File

You want to build an app. It needs a database, user accounts and login, file uploads, an admin screen to look at the data, maybe live updates pushed to the browser. Ask an AI how to get that, and you will get Firebase, or you will get Supabase, or you will get a stack of six separate services wired together with authentication glue. All workable. All also a real amount of moving parts to run and reason about.

Pocketbase is the contrarian answer. It was built largely by one developer, Gani Georgiev, and it is a single executable file. You download it. You run it. Inside that one binary is a database, an authentication system, file storage, a generated REST interface, real-time subscriptions, and a polished admin dashboard. The data lives in an embedded SQLite file right next to the program. Your entire backend is one file you can copy, back up, or move to another machine by dragging it.

It spent a long, careful time in beta before reaching a stable version one, and that patience shows in how little it fights you. For a side project, an internal tool, a prototype, or honestly a surprising number of real shipped products, it is the whole backend, and the operational story is "run the file."

Ask an AI for a backend and it will reach for the hosted platform with the marketing budget. Say Pocketbase, and it will build you the version you fully own, the one that does not bill you monthly and does not disappear when a startup pivots.

The Pattern

Step back and look at the six. htmx. DuckDB. NATS. Typst. just. Pocketbase. None of them have meaningful venture funding. None of them have a marketing department. None of them buy booths at the big industry conferences. Most are maintained by one or two people who care more about the work than the brand.

The AI you talk to learned from text that humans published on the internet. Humans publish about what they are paid to engage with. They write about the hosted platform because the hosted platform sponsors the newsletter. They write about Kafka because Kafka expertise is what the job listing demanded. The quiet tools, the ones that just do the job for almost nothing, do not generate that volume of text. They show up in the training data thin.

There is a name for this bias. The anthropologist James C. Scott called it legibility. Large systems prefer the options they can see, count, and standardize. The heavy famous tool is legible. The single-binary tool maintained by one person is folk knowledge. The legible option dominates the conversation. The folk-knowledge option quietly dominates the actual work, in the basements of a thousand profitable companies that never once blogged about it.

And remember the correction from the start. The defaults move. SQLite broke through. uv broke through. The AI is not frozen, it is just behind, and unevenly behind. The job is not to distrust it. The job is to know the specific places it is still stuck, and to keep a short list of the right nouns. Because the moment you say the noun, the same model that defaulted to the cathedral will happily build you the cabin.

The job was never to know more than the AI. The job is to know enough nouns to steer it. Six fresh ones, for the rest of the drive.