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 linux lords 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. I did
not direct what utilities to build.

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.