gawk4ai: Everyday Machine Learning in Under 400 Lines of gawk

A repository called gawk4ai, titled "tinyai: AI, written small" in its README, claims that an LLM-assisted session of about four hours rebuilt the everyday core of machine learning, including naive Bayes, nearest neighbor, tf-idf, discretization and ranking, in under 400 lines of gawk. The method, in the README's words, is one sentence long: "good — now write it smaller." The numbers are the author's own, and we did not rerun them, but the argument behind them is worth reading.

This post summarizes the claims, checks them against what the README actually shows, and explains where the approach helps and where it fails. For related small-model thinking, see our posts on Coinbase's fine-tuned small model that beat a frontier model and Samsung's sub-1-bit LLM.

Quick facts

The claim: less intelligence is the goal

The README opens with a thesis: "The point of intelligence is less intelligence." It argues that experts see fewer, more relevant things (it cites a classic study of chess players), that people systematically overlook subtractive changes when asked to improve something, and that complexity is often a sales pitch. It contrasts this with the "Big Blob of Compute" view of AGI and points out the scale of announced data-center spending, then says most work is "a thousand tasks smaller than AGI, due Friday."

From there it proposes a standard: deliver two things for any analysis. First, the state-of-the-art result. Second, the tiny baseline that gets nearly the same answer with a fraction of the resources. "A method you cannot shrink is a method you do not yet understand," it says.

The history section links the idea to Doug McIlroy's 1964 memo that led to the Unix pipe, and to the 1986 exchange in which a six-line shell pipeline answered the word-frequency problem that Knuth had solved in ten pages of Pascal. It also cites a 1996 report that students wrote their best AI course work in gawk, because exploratory code needs cheap rewrites and one flexible data structure.

What the numbers say

The README reports three comparisons against the library an analyst would normally reach for, "same files, same splits, same scoring."

1. Classification on ten files (twenty shuffles, 50:50 train/test): discretized naive Bayes averages 79.6% accuracy against LightGBM's 84.3%. The gawk tool is best or tied on five of ten files, LightGBM on nine. The whole gawk experiment finishes in 26 seconds against 439.
2. Text with rare classes (four files, roughly 1% positive): tf-idf feeding complement naive Bayes averages 81.7% macro recall against 65.0 for a class-balanced LinearSVC, and wins on all four. Here the SVM is faster, 154 seconds against 285.
3. Optimization under a label budget (ten files, fifty shuffles): labelling 25 rows and checking the five best-ranked returns a row in the best 5.8% of the space, where checking five random rows returns 16.3%.

The README is candid about the first result: LightGBM is the better classifier, and it runs at defaults built for far larger data. On 46 training rows, the default minimum child samples setting means it builds a hundred two-leaf stumps. Tuned for small data, it would pull further ahead. So the author's claim is not that gawk wins but that there is an "exchange rate": a few points of accuracy for two orders of magnitude less code to install, read and trust.

That framing is sensible. Be careful with the details: these are small datasets, the baselines run at defaults, and the experiments were designed and run by the same person who wrote the tool. Treat the numbers as an illustration of the tradeoff, not a benchmark. The idea of comparing against a deliberately simple model is old and sound, and the README cites it as the "straw man" approach to verification.

The "write it smaller" prompting lesson

For people who use coding agents, the most useful part may be the process. The README says typical LLM sessions overwhelm the user with dialogue and code. Here the author asked the model to clarify when something did not make sense, and once a script ran, the next prompt was always "good — now write it smaller." The result stayed small enough to read in full, which kept the human "genuinely in the loop," and that made later prompts better informed.

This is a practical counter to a common failure: agents that produce more code than you can review. A small-output constraint doubles as a review aid. It pairs well with other ways to limit agent output, like the graph-based approach in code-review-graph and the local-search tricks in the AutoIndex write-up.

The attack-surface argument

One of the README's ten arguments is security. It counts the code a typical Python data stack pulls in: on the author's machine, the installed numpy, scipy, scikit-learn and LightGBM ship 995,456 non-blank lines of Python, Cython and C, not counting LightGBM's own engine, which arrives as a compiled library. The eleven gawk scripts come to 223 lines and depend on nothing but gawk. It cites the 2024 xz-utils backdoor as an example of supply-chain risk and argues that a few hundred lines can be audited in an afternoon.

That is a real point as AI-written code increases the number of dependencies projects take on. It does not mean a small tool is automatically safe, but auditable code is easier to trust. For a sense of how dependencies get abused in agent workflows, see our coverage of the Railway and OpenRouter key theft.

Why gawk, of all languages

The README makes a specific case for the choice. Gawk reads data in one pass, has one flexible data structure (the associative array), and has syntax small enough to learn in an hour, so a model that writes it makes few structural mistakes and a person can review the result in one sitting. The scripts read text streams and write text streams, which means they compose with ordinary Unix tools like sort and head instead of requiring a framework.

That fit is also why the experiment works as a demonstration of LLM-assisted coding. A language with a tiny surface area gives the model less room to wander and the reviewer less to check. Whether the same discipline holds in a language with a larger ecosystem is the real test, and the author admits to switching to Lua or Python when data structures get complicated.

When not to use it

The README ends with its own limits, which are worth repeating:

• Genuinely hard perception tasks such as vision, speech and open-ended generation. Use the big model and keep the tiny tool as the baseline that proves the big model earns its cost.
• Huge data with a real deadline. Gawk is a single-core text engine.
• Deeply nested data. It offers strings, numbers and hash arrays only.
• Deep numerics, where decades of engineering live in libraries like LAPACK.
• Interactive GUIs and designs with many parts sharing complex state.
• Regulated or contractual stacks that require supported, certified libraries.

The author also admits that students often prefer the Python ports to the gawk originals, and suggests handing students the working gawk and asking them to port it, since the port forces line-by-line understanding.

How to use the idea in your own work

You do not need to adopt gawk to use the principle:

1. Build the tiny baseline first. A naive Bayes or tf-idf script takes minutes and tells you how much a heavier model really adds.
2. Ask your coding agent for the smaller version. After a working script, prompt it to remove code and keep tests passing.
3. Report two numbers. Show the best result and the baseline, with cost and runtime for each.
4. Count dependencies. Before adding a package, ask how much of the problem survives fifty lines of your own code.
5. Keep a human-readable artifact. If the final script cannot be read in one sitting, you may not have finished.

For model-level versions of the same idea, see how antirez's DwarfStar keeps local inference small, and how Rigel matches a larger model with far less pretraining compute.

What to watch

The repo is new and small, and we found no independent replication. The open questions are whether the accuracy gap holds on larger, noisier datasets, how much of the 26-second runtime advantage comes from avoiding library startup costs, and whether the "write it smaller" loop generalizes to tasks with richer data structures. The ideas, though, are testable on your own data in an afternoon.

Related reading

• Coinbase's fine-tuned Qwen3.5 9B fraud agent
• Samsung LittleBit: a 13B model under 1GB
• code-review-graph: stop agents re-reading your repo
• AutoIndex: local search for agents, claim vs README
• DwarfStar DS4 local inference
• Rigel 2.3B: efficient pretraining

Details are accurate as of October 29, 2026; results are as reported in the project's README. Reference: the GNU gawk manual.