The Rewrite of Engineering Toolchains

In 1974, Ken Thompson and Dennis Ritchie, on a PDP-11 at Bell Labs, established Unix's classic design philosophy: a program should do one thing only, and do it to its extreme.

Through pipes, shell scripts, and Makefiles, this philosophy defined the tool paradigm of software engineering for the past fifty years.

The core of this entire system is precise control.

Consider a typical log analysis command: grep ERROR log.txt | sort | uniq -c | sort -rn | head -10. The entire execution chain is transparent and decomposable, with predictable output: grep filters error lines, sort performs basic ordering, uniq -c counts duplicate entries, the second sort reverses the order, and head truncates to the top ten results.

A Unix pipeline is like a set of precisely meshed gears, where each tool's standard output becomes the next tool's standard input. The entire chain is transparent, logically determined, execution-controlled, and fully reproducible.

Now, a new tool philosophy is infiltrating and reshaping this fifty-year-old system: the fuzzy intent paradigm.

"Fuzzy intent" here does not mean imprecise output — it means the user no longer needs to manually define the full execution process.

The user need not memorize grep, sort, uniq, head, nor understand pipe communication principles, nor recall parameter rules and edge cases. One only needs to state the goal — extract the ten most frequent error types from the logs — and AI will either generate the executable command or produce the analysis result directly.

This is not merely an efficiency improvement. It is a fundamental restructuring of the relationship between humans and their tools.

Under the precise control paradigm, tools are extensions of human capability. The user knows the tool's boundaries and rules, can anticipate the full execution flow, grasp every operational detail, and replay every step — maintaining absolute agency over the process.

Under the fuzzy intent paradigm, tools become intent translators. The user defines only the end goal; the model autonomously plans execution paths, orchestrates tools, and handles intermediate steps. The user receives only the final result, with little visibility into — or ability to verify — the model's internal decision chain.

These two paradigms are fundamentally incompatible at the logical level, representing two entirely different engineering philosophies. Today, the entire engineering toolchain is migrating from traditional precise control toward the fuzzy intent paradigm.

The core value of the precise control paradigm is not execution speed — it is unbounded composability.

Unix pipes can be freely concatenated and nested because all tools share a universal plain-text stream interface. Input and output formats are standardized, with no special encapsulation. As long as a program reads and writes text, any two tools can be seamlessly connected, building highly flexible automation workflows.

Today's mainstream AI tools do not yet possess this standardized composability.

This limitation is not a fundamental technical barrier — it stems from the inherent stochasticity of large model output. Natural semantic expression is free-form; output formats lack unified standards. The same prompt — "list all expired SSL certificates" — may return a structured table, a prose paragraph, or a bulleted summary. The output form is dynamically generated by the model, with no fixed standard.

This characteristic makes AI output incompatible with traditional toolchain invocation logic. Downstream tools depend on fixed-format input, but AI output is unpredictable in form, making it difficult for conventional programs to consume, chain, or further process.

Today's AI tools are essentially terminal tools: they receive user intent, produce a final result, and the workflow terminates there. They can only sit at the end of a pipeline, unable to participate in multi-stage composition within a workflow. This closedness severely limits AI's depth of application in engineering automation.

To enable AI tools to be freely chained into long automation workflows, the industry must establish a new universal specification: a structured intent protocol.

Future tool inputs will no longer be unconstrained natural language strings, but structured objects containing a standardized intent description, fixed output format, fault constraints, and result verification rules. This protocol is not yet mature, but it is an inevitable direction — AI tools will not remain confined to single-turn terminal interactions forever.

Under the precise control paradigm, scripts are the core carrier of automation.

A sequence of deterministic commands, assembled into a script file, can be executed repeatedly and stably, producing identical results every run. The core value of scripts is process reproducibility: they completely crystallize every execution step, unaffected by personnel, time, or environment, with stable determinism.

Under the fuzzy intent paradigm, prompts become a new automation carrier, forming a complementary relationship with scripts.

A prompt does not define specific execution steps — it describes only the business goal and constraints. The same prompt, depending on model version, random sampling, and context differences, will often produce different outputs at different times.

Prompts are not an evolution of scripts — they are a differentiated automation approach. Scripts suit standardized, high-frequency, strictly reproducible tasks, crystallizing the complete execution process. Prompts suit tasks with variable scenarios, non-fixed workflows, and no requirement for exact reproduction — they lock in only the business intent.

Engineering teams in the AI era will not abandon scripts entirely. Core production processes — compilation, builds, deployments, data migrations — must rely on scripts to guarantee reproducibility and operational stability. There is no substitute.

But auxiliary, non-standardized tasks — log analysis, fault troubleshooting assistance, code interpretation, documentation generation — will gradually shift to prompt-driven modes. These tasks have variable inputs, no fixed execution paths, and the flexibility and development cost advantages of intent-driven approaches far exceed those of hard-coded scripts.

Scripts and prompts are not in competition. They are two complementary approaches within a modern automation system, dividing labor between them.

In 1976, Stuart Feldman introduced Make, whose core design is dependency-driven incremental building: when source file file.c is modified and its timestamp is newer than the compiled output file.o, recompilation is triggered automatically.

Nearly fifty years later, this underlying logic still runs through modern engineering systems: GitHub Actions, Dockerfiles, Terraform — all are derivative implementations of the "resource change triggers incremental execution" pattern.

AI cannot replace Makefiles, but the core reason is not insufficient intelligence — it is that they solve engineering problems on entirely different dimensions.

Make handles deterministic dependency graphs: change relationships between files, configurations, and resources can be exhaustively enumerated and explicitly defined. Trigger rules are fixed. Execution results are predictable and reproducible.

AI excels at handling fuzzy, rule-free problems: potential code optimization points, latent performance degradation, hidden logic vulnerabilities, business adaptation risks. These scenarios have no static dependency graphs and can only be identified through model reasoning.

AI is therefore a complement to the build system, not a replacement. Make governs the "known knowns" of engineering, ensuring core process stability and control. AI probes the "known unknowns" and "unknown unknowns," capturing hidden risks and optimization opportunities that traditional rules cannot cover.

Future engineering pipelines will add AI-assisted verification layers alongside Make's deterministic processes: commit quality checks, latent risk scanning, performance fluctuation assessment, code standards optimization — enhancing overall engineering governance without disrupting existing stable workflows.

Precise control and fuzzy intent are not opposed to each other. They suit different engineering scenarios and will coexist long-term. Developers must actively draw clear boundaries between their domains of application.

For scenarios demanding strong determinism — compilation and builds, production deployments, database migrations, cryptographic operations, core transaction pipelines — the precise control paradigm is irreplaceable. These scenarios have near-zero tolerance for error; operational mistakes carry irreversible risk. Probabilistic, non-deterministic execution logic is not permitted.

For intent-driven efficiency scenarios — code generation assistance, documentation writing and optimization, intelligent log analysis, fault tracing and reasoning, content summarization — the fuzzy intent paradigm has the advantage. Implementing these tasks through precise coding carries extremely high development and maintenance costs; intent-driven approaches significantly reduce cost while improving efficiency.

The core bridge connecting these two paradigms is precisely the structured intent protocol mentioned earlier.

It discards the looseness of pure natural language prompts while avoiding the rigid verbosity of code scripts — a new standardized carrier for the AI era: explicit business intent, locked output format, defined fault boundaries, reserved verification rules. More rigorous than prompts, more flexible than code, it bridges the gap between traditional precision tools and AI tools.

The Unix designers of 1974 did not foresee AI, but they left behind a profoundly valuable engineering insight: simple, universal interfaces are far more valuable than individually powerful tools.

Pipes and text streams are the universal substrate of the Unix toolchain. Their advantage lies not in power but in extreme generality and unified rules: all tools need only adapt to basic text reading and writing to freely combine and build complex workflows.

The evolution of the AI-era toolchain follows the same underlying logic, only the carrier of the universal interface has upgraded from text streams to structured intent protocols.

Through unified structured standards — encapsulating user intent, output specifications, verification rules, and constraint conditions — any AI tool's output can be recognized, read, chained, and further processed by any other AI tool, building a complete AI toolchain ecosystem.

This protocol has not yet landed in mainstream technology stacks, but it is an inevitable direction for the industry. The core value of tools lies in connection and composition. AI tools will ultimately break beyond the short chain of "human — single tool — single output."

When standardized intent protocols achieve widespread adoption, the comprehensive AI transformation of the software engineering toolchain will have truly begun.