There is an unspoken rule in software engineering: the more moving parts you introduce, the more ways your system can fail at 2 AM.
When teams rushed into building with LLMs over the past two years, they treated complexity as a proxy for sophistication. We saw 14-agent orchestration frameworks where agents scheduled meetings with other agents to write a database migration. We saw 30-step prompt chains that fell over if OpenAI returned an unexpected punctuation mark.
I took the opposite path on my personal infrastructure and client engagements: Minimal AI.
Strip away the speculative abstractions. Measure value in minutes recovered and deterministic outcomes, not tokens burned.
The Minimal AI Triad
When I build or audit AI systems in 2026, every feature has to survive three tests before it gets to touch code:
-
Could this just be a bash script or a standard library call?
If a deterministic script or a simple regex can do the job with 100% reliability in 4ms, sending a prompt across the WAN to an LLM is architectural malpractice. -
Is the interface conversational or functional?
If you need a human-in-the-loop review, conversational MCP interfaces make sense. If you are synchronizing 500 records or organizing mailbox folders, expose a sharp Unix CLI (imail,wa,bb). Stop wrapping batch routines in multi-turn dialogues. -
Who owns the failure boundary?
Autonomous agents must never have ambient write access to unconstrained production surfaces. Strict, typed contracts and explicit human gates beat "trusting the model's intent" every single time.
Less Ceremony, More Output
Minimal AI isn't about being anti-model—it's about respecting the boundaries of probabilistic systems. The engineers shipping real business value right now aren't the ones boasting about 50-step autonomous loops; they're the ones pairing rock-solid Unix tooling with surgical model calls.
Do less. Constrain the scope. Let the results speak.
