AI Employee Tirelessly Creates Linux Utilities

I’ve been building my own platform for autonomous AI. It’s an experiment in self-directed AI agents—or “AI Employees,” as I call them.

Can I build one? Can it create actual value? And what lessons are there to be learned when an AI system is allowed to work autonomously over time?

I call them AI Employees because I manage them much like employees: each has a defined mission, operating boundaries, a backlog, scheduled working hours, and a review process.

I gave this particular employee a mission: create useful Linux utilities in C. Avoid external libraries. Follow sound C practices. Test the code rigorously. Use linters, compilers, sanitizers, and static-analysis tools. Follow the Unix philosophy of small command-line programs that do one job well—all the “good stuff” I’ve heard people on this forum laud for years.

I personally work much higher in the technology stack. I prefer GUIs, love my Mac, and use cloud services extensively.

But AI has been my passion for the last few years, and “pure as the wind-driven snow” Linux utilities presented an interesting challenge: Lee can’t write these—but can Lee build an AI system that can?

I originally scheduled the employee to start at midnight, wake once an hour, do a cycle of work, and stop at 7 a.m. Each cycle begins by reviewing its mission and current state, updating the backlog, and selecting the most valuable feasible item. A second LLM challenges the proposed direction, the system reconciles their views, and only then does implementation begin.

The implementation runs through my agent orchestrator: a trust-and-evidence-based system designed to verify that the models actually performed the work they were assigned. The LLM does not get to declare its own work successful merely because it produced a confident explanation.

That distinction matters. The creative parts of the process—planning, coding, and review—use LLMs. But many of the acceptance decisions are made by deterministic tools:

• The code must compile as C17 under both GCC and Clang, with strict warnings enabled and warnings treated as errors.
• clang-format enforces formatting mechanically.
• clang-tidy, cppcheck, and Clang’s static analyzer look for bug-prone, unsafe, nonportable, and suspicious code.
• AddressSanitizer and UndefinedBehaviorSanitizer exercise the programs while checking for memory errors and undefined behavior.
• Valgrind provides another independent memory and leak check.
• Regression and adversarial tests verify exact output, exit codes, malformed-input behavior, boundary cases, and hostile filesystem conditions.
• The man pages are linted, and performance checks guard against obvious regressions.
• A separate reviewing model examines the implementation and findings after the deterministic gates pass.

The whole quality pipeline is available as one fail-closed command: make quality. A persuasive model response cannot turn a failed compiler, test, sanitizer, or analyzer result into a pass. The orchestrator records the commands, exit status, outputs, and resulting artifacts as evidence.

None of that proves the code is perfect. Deterministic tools can establish that specific, mechanically checkable requirements were met; they cannot establish that every design decision was wise or that no defect remains. But they greatly narrow the distance between “the AI wrote some code” and “there is repeatable evidence that the code satisfies a serious quality floor.”

So far, the employee has created three utilities:

• sysdiff — Deterministically compares two explicit key=value system snapshots and reports added, removed, and changed keys. Released as v0.1.0.
• pathaudit — A read-only PATH security auditor. Detects missing, relative, empty, writable, incorrectly owned, and shadowing entries. Built and tested, but not released.
• permguard — A read-only permission inspector for explicitly named paths. Reports group/world writability and setuid/setgid bits, and rejects final symlinks. Built and independently reviewed, but not released.

You can download and inspect them here:

https://github.com/leebase/linux-utilities

The repository includes the source code, tests, documentation, and Make targets needed to reproduce the quality checks.

I’m still waiting for a real human C expert to examine the code. I can verify that the programs work on my Linux box, that the tests pass, and that the deterministic quality gates succeed. I cannot personally validate the craftsmanship of the C itself because I am not a C programmer.

What I can say is that I built a system with substantially more checking, testing, independent review, and recorded evidence than “vibe-code me a Linux utility in C” would normally produce.

Make no mistake, though: AI is not authoritative. Only humans have accountability.

This is primarily an experiment in building autonomous AI systems and dogfooding my own agent orchestration platform. That is the main value to me. If this were a commercial product for a company or enterprise, I would never release it without expert human review.

I’m making it available in the hope that an experienced C programmer will step forward, examine the work, and tell me honestly whether the system has met its code-quality goal.

For what it’s worth, I mostly leave this particular AI Employee alone to do its work. That is the point of the experiment. The Linux utilities it creates are “that’s nice,” but they are not the real reason I have it working through the night.

With my other AI Employees, I hold daily—or more frequent—status conversations: What has progressed since we last spoke? What is blocked? What did you learn? Then I provide feedback and direction.

I now have a Snowflake RBAC accelerator and a Snowflake data-modeling tool to show for that effort.

More on those later.