AI coding tools are about quality, not only speed
AI coding tools quality refers to how well AI-generated code meets long-term software quality assurance goals, including architectural integrity, maintainability, and compliance with code governance standards instead of focusing only on developer productivity AI metrics or raw output volume. That framing is shaping a new debate across language communities and tool vendors. Linus Torvalds argues AI is a “great new tool” that boosts productivity in the way compilers once did, but warns that building systems expected to last for decades still requires humans who understand architecture and the generated code, not only prompts. His frustration targets slogans like “99% of our code is written by AI,” which he compares to the unnoticed reality that “100% of their code is written by compilers.” In parallel, language designers and open-source maintainers are pushing back on “vibe coding,” where AI output ships without serious review.
From human-in-the-loop to closed-loop AI agents
The first generation of AI coding tools kept developers at the center: prompt, inspect the draft, then refine. Facebook’s Hack language creator Julien Verlaguet says this misses the core problem. “Building correct software has always been an architecture problem disguised as a coding problem,” he argues, and AI has made that architecture gap more urgent. His company SkipLabs introduced Skipper, a closed-loop coding agent that behaves more like a compiler pipeline than a chat assistant. Developers provide a plain-language description or an OpenAPI specification, and Skipper returns a complete, validated backend service without a human review cycle. The review and refinement happen inside the agent. In this theory, AI code automation should move from speeding up typing to owning an end-to-end process, while still being constrained by strong specifications and automated checks instead of casual human feedback.
Rust maintainers fight ‘vibe coding’ with strict governance
Open-source maintainers are feeling the downside of unconstrained developer productivity AI workflows. In the Rust ecosystem, the same strict compiler and borrow checker that make Rust attractive for safe systems code also make it appealing to automated agents. Rust’s deterministic compile-time checks give AI tools a tight feedback loop, producing code that compiles yet often ignores broader design. The result is a surge of low-effort, AI-generated pull requests to rust-lang/rust, each one consuming continuous integration time, compute for tests and human review capacity. Reviewers must untangle syntactically correct but architecturally confused changes. In response, Rust contributors drafted a conservative policy for automation, stating that large language models may read and analyze code but are not suitable for creating it. This push for stricter code governance standards shows maintainers prioritizing software quality assurance and safeguarding repositories against “vibe coding” sabotage and operational overload.
Zig’s no-AI stance and the culture of uncompromising quality
Zig’s creator Andrew Kelley represents another quality-first reaction to AI code automation. Zig aims to match C’s performance while reducing its “footguns,” but the project’s culture goes further than language design. Zig maintains a no-AI policy in its code of conduct because AI-generated contributions have been “invariably garbage,” consuming review effort that maintainers would rather invest in human-written patches. At the same time, Kelley frames Zig’s roadmap around “uncompromising perfection” before declaring a 1.0 release, even as other languages chase rapid growth. His own path—moving away from Go, C++, and Rust after hitting reliability and productivity walls—shows a bias toward clear, predictable behavior over speed. That stance highlights a growing divide: should AI coding tools maximize developer productivity today, or slow down and enforce higher bars for correctness, maintainability and long-lived architectures?
Will AI augment or replace software decision-making?
Beneath these arguments lies a strategic question: should AI coding tools aim to enhance developers, or replace much of their decision-making? Torvalds describes AI as another step in the historical progression from machine code to compilers, arguing that “true software engineering” still needs people who understand system architecture and the code they ship. SkipLabs’ Skipper embodies a bolder vision: a closed-loop agent where developer involvement is “optional,” so long as specifications and automated tests are strong enough. Meanwhile, Rust and Zig communities enforce code governance standards that resist handing over architectural control to AI systems, even when doing so might increase short-term productivity. Taken together, these approaches suggest that the most credible future for AI coding tools quality is one where automation handles repetitive construction, while humans remain accountable for design, governance and the long-term behavior of software.
