DEV Community: Ronak Parmar

Why I Reimplemented 22 Unix Tools in Go for AI Agents

Ronak Parmar — Mon, 06 Apr 2026 14:12:20 +0000

I spent three weeks rebuilding ls, grep, cat, find, stat, diff, and 16 other Unix coreutils in Go. Not because the originals are broken — they're masterpieces of systems programming that have survived decades of use. I rebuilt them because AI coding agents are terrible at reading their output.

The Problem Nobody Talked About

Every time an AI agent runs ls src/, it receives something like this:

-rw-r--r--  1 user  staff  2048 Apr  6 12:00 main.go
drwxr-xr-x  3 user  staff    96 Apr  6 11:00 internal
lrwxr-xr-x  1 user  staff    12 Apr  6 10:00 link -> main.go

The agent has to figure out which column is the filename. Which is the size. Whether that d at the start means directory. Whether Apr 6 means this year or last year. It guesses. Sometimes it guesses wrong. And every wrong guess costs tokens, introduces errors, and degrades the quality of the code it writes.

Now multiply that by every grep, every cat, every find the agent runs in a single session. The token waste is staggering. The parsing fragility is a constant source of subtle bugs.

The Insight

AI agents don't need pretty terminal output. They need structured data. They need to know that main.go is 2048 bytes, was modified 3600 seconds ago, is written in Go, has MIME type text/x-go, and is not a binary file. They need this information labeled, unambiguous, and machine-readable.

So I asked: what if ls returned XML?

<ls timestamp="1712404800" total_entries="3">
  <file name="main.go" path="src/main.go" absolute="/project/src/main.go"
        size_bytes="2048" size_human="2.0 KiB"
        modified="1712404800" modified_ago_s="3600"
        language="go" mime="text/x-go" binary="false"/>
  <directory name="internal" path="src/internal"/>
  <symlink name="link" target="main.go" broken="false"/>
</ls>

Zero ambiguity. Zero parsing. The agent reads the attributes and knows exactly what it's looking at. No regex to extract filenames from column-aligned text. No heuristic to determine if something is a directory. No guesswork.

Why XML and Not JSON?

Good question. JSON is the lingua franca of APIs. But XML has a structural advantage that matters for AI context windows: attributes.

Compare these two representations of the same file:

<file size_bytes="2048" language="go" mime="text/x-go"/>

{"size_bytes": 2048, "language": "go", "mime": "text/x-go"}

The XML version is 40 characters. The JSON version is 60. That's a 33% difference. When you're listing 1,000 files, that's tens of thousands of tokens saved. AI context windows are expensive and limited. Every character counts.

That said, aict supports --json for every tool. The schema is identical. Use whatever your pipeline prefers.

Why Go?

Three reasons:

Single binary. Go compiles to a static binary with zero runtime dependencies. aict is one file you drop on a system and it works. No pip install, no npm install, no shared libraries to manage. For a tool that's supposed to replace coreutils, this is non-negotiable.

Standard library only. Every feature — regex matching, MIME detection, filesystem walking, XML encoding — uses Go's standard library. Zero external dependencies means zero supply chain risk, zero version conflicts, and the ability to audit the entire codebase in an afternoon.

Performance is good enough. Yes, aict grep is slower than ripgrep. Yes, aict ls is slower than eza. But we're talking 15ms vs 2ms for listing 1,000 files. The overhead comes from language detection, MIME sniffing, and structured output — features that are the entire point of the project. For normal codebases, the difference is imperceptible.

What I Built

Twenty-two tools across five categories:

File inspection: cat, head, tail, file, stat, wc
Directory & search: ls, find, grep, diff
Path utilities: realpath, basename, dirname, pwd
Text processing: sort, uniq, cut, tr
System & environment: env, system, ps, df, du, checksums

Plus a git subcommand suite (status, diff, log, ls-files, blame) and an MCP server that exposes every tool as a callable function to AI assistants like Claude and Cursor.

Every tool supports three output modes: XML, JSON, and plain text. Every error is structured data in stdout, never stderr. Every path is absolute. Every timestamp is a Unix epoch integer.

The MCP Server

This is where it gets interesting. aict ships with an MCP (Model Context Protocol) server binary called aict-mcp. You configure it in Claude Desktop or Cursor, and suddenly every tool becomes a typed, callable function.

The AI agent doesn't shell out to run aict ls src/. It calls the ls function with {path: "src/"} and receives structured JSON. No shell spawning. No output parsing. No ambiguity.

This is the future of how AI agents interact with filesystems. Not by typing commands into a terminal and reading the output like a human would. By calling typed functions and receiving typed responses.

What I Didn't Build

I intentionally excluded write operations: cp, mv, rm, mkdir, chmod, chown. These are dangerous when called by AI agents without human confirmation. aict is a read-only tool. It observes, it doesn't modify.

I also didn't try to match GNU coreutils flag-for-flag. Where a flag made sense for the AI use case, I added it. Where it didn't, I skipped it. The goal is not compatibility — it's utility for AI agents.

The Honest Benchmark

I benchmarked aict against GNU coreutils. Here are the results:

Tool	GNU	aict	Ratio
`ls` (1,000 files)	~2ms	~15ms	7×
`grep` (100k lines)	~1ms	~100ms	100×
`find` (deep tree)	~2ms	~9ms	5×
`cat` (100k lines)	~1ms	~23ms	17×
`diff` (1,000 lines)	~1ms	~10ms	10×

grep and cat are slow because every file is MIME-typed and language-detected. Use --plain to skip enrichment when you only need content. The trade-off is intentional: more tokens spent on parsing vs. more semantic information returned.

Is This Actually Useful?

I've been using aict with Claude and Cursor for two months. The difference is noticeable. The agent makes fewer mistakes about file types. It doesn't confuse directories with files. It correctly identifies binary files before trying to read them. It understands the structure of a codebase faster.

The token savings are real. A directory listing that used to cost 2,000 tokens in plain text now costs 800 in XML with three times the information density. Over a typical coding session with dozens of tool calls, that adds up.

Open Source

The project is MIT licensed and on GitHub. It's written in Go with zero external dependencies. You can audit the entire codebase in an afternoon. I'd love contributions — new tools, performance improvements, bug fixes.

If you build AI agents that interact with codebases, give it a try. Your agent will thank you. And if it doesn't work for your use case, that's fine too. GNU coreutils aren't going anywhere.

The repo is at github.com/synseqack/aict.

I got tired of configuring the same stack over and over, so I built a modular project assembler

Ronak Parmar — Wed, 25 Mar 2026 13:26:48 +0000

Every side project I started followed the same ritual.

Find a starter. Clone it. Realize it doesn't have the exact
combination I need — say, Next.js with Express as a separate
backend, PostgreSQL, JWT auth, and Tailwind. Start adding things.
Watch the tsconfig break. Spend 45 minutes on Stack Overflow.
Finally start actually building at 11pm, mentally exhausted.

I did this enough times that I started keeping a folder of
"my personal starters." Which worked until I had six of them and
they were all slightly different and none of them had the latest
versions of anything.

So I built Foundation CLI instead.

What it is

Foundation CLI is a dependency-aware project assembler. You describe
your stack — frontend, backend, database, auth, UI, deployment — and
instead of copying static template files, it:

Resolves the full module dependency graph
Detects and handles conflicts automatically
Merges configs intelligently (deep merge for package.json, key-dedup for .env, semver intersection for requirements.txt)
Commits everything atomically — or not at all

npx @systemlabs/foundation-cli create

The part that was interesting to build

The dependency resolver was the core challenge. Modules don't
conflict by name — they conflict by capability. "Auth JWT" and
"Auth OAuth" are different implementations of the same capability.
The resolver uses capability tokens, not module IDs, to detect this.

Then it runs Kahn's algorithm to build a topological sort of the
module execution order — because if Tailwind needs to run after
Next.js (to patch the config correctly), that dependency needs to be
explicit and enforced.

Conflicts come in two tiers:

Hard conflicts — two auth modules, two frontends. Block the entire scaffold.
Advisory conflicts — Express + Cloudflare Workers (Express doesn't run on the edge). Warn, but don't block.

The config merge problem

This is the part that template copiers get wrong. When you add
Tailwind to a Next.js + Express project, three different files need
to change:

package.json — new devDependencies
tailwind.config.js — new file
globals.css — Tailwind directives
Possibly next.config.mjs — PostCSS config

A static template can't do this. You either have a template per
combination (exponential), or you have a module system that knows
how to merge.

Foundation CLI's merge engine handles this per file type. JSON files
get deep-merged with conflict detection. .env files get
key-deduplicated. docker-compose.yml gets service-merged.
requirements.txt gets semver-intersected.

Zero partial scaffolds

Every write goes through a FileTransaction. Files are staged to a
temp directory. If anything fails — a template render error, a
missing dependency, a hook failure — the temp dir is deleted and
the output directory is left completely untouched.

You either get a complete, working project or you get nothing. No
mystery half-generated directories.

What's in it

28 built-in modules across 7 categories
8 project archetypes (SaaS, AI App, E-commerce, API Backend, etc.) with pre-filled smart defaults
Plugin SDK — third-party modules publish to npm with foundation-plugin keyword
TypeScript throughout, strict mode, all generated projects pass tsc --noEmit

Try it

npx @systemlabs/foundation-cli create

Repo: https://github.com/ronak-create/Foundation-Cli

I'd love feedback — especially if you've built something similar
and solved the config merge problem differently. The current
approach works but I'm not convinced it's the best design.

Open-sourcing Foundation CLI — a dependency-aware project scaffolding tool

Ronak Parmar — Mon, 16 Mar 2026 10:06:11 +0000

I’ve been experimenting with a CLI tool for my own workflow that tries to simplify starting new projects.

The idea is that instead of manually wiring frameworks, databases, auth, etc., you describe the stack you want and the CLI generates the project structure.

For example something like:

"I want a SaaS with Next.js, Express, PostgreSQL and JWT auth"

The tool resolves dependencies, merges configs, and sets up the integration code automatically.

I'm curious if people here actually find tools like this useful, or if most devs prefer starting projects manually.

Would love to hear how others approach bootstrapping new projects.

Github