Vercel has released Zero, described as a programming language for agents. A systems language for small native tools, explicit effects, predictable memory, and structured compiler output.
It is an interesting artifact. It is also, in my view, aimed at the wrong layer.
The problem is real. Agentic software development changes the shape of engineering work. When an AI agent is allowed to operate inside a repository, the bottleneck is no longer merely whether it can produce plausible source code. The bottleneck becomes whether the repository gives the agent a reliable operating environment: build commands, test gates, sanitizer gates, e2e infrastructure, benchmark thresholds, package checks, release discipline, and clear escalation points.
That is the actual interface.
Not the programming language.
The Language Is Not the Bottleneck
I understand the temptation. If agents are now writing code, perhaps we should design a language for agents. Make the effects explicit. Make memory predictable. Make diagnostics structured. Make compiler output easy to consume. Make the world small enough that the agent cannot wander too far.
That sounds coherent until you remember one inconvenient fact: LLMs already know the existing languages.
They know C. They know CMake. They know shell. They know Makefiles. They know compiler output. They know sanitizer failures. They know common linker errors. They know what a broken include path smells like. They know enough of the Unix build world to be useful, and they get much better when the repository gives them a hard feedback loop.
I use AI agents against multiple C codebases, including old-fashioned C89-style projects, CMake presets, fuzzing, benchmarking, Docker Compose e2e environments, package gates, release gates, and GitHub release workflows. The surprising result is not that C is too hard for agents.
The surprising result is that C works extremely well when the harness is serious.
That is the point Zero seems to miss.
The problem is not that we need a new systems language. The problem is that most repositories are operationally illegible.
Agents Do Not Need JSON. Systems Do.
One of the recurring arguments around agent-oriented tooling is structured output. Diagnostics should be machine-readable. Compiler output should be JSON. Tools should emit stable codes. Agents should consume structured facts.
There is a truth there, but it is often misstated.
Agents do not need JSON in the way deterministic machines need JSON. A competent LLM can read compiler prose, half-broken logs, pseudo-JSON, test failures, stack traces, and human comments. It can usually extract the useful signal from mess.
Typed clients, CI systems, release scripts, dashboards, retry logic, and policy gates need structured output. They are deterministic machines. They need stable shapes.
So the better conclusion is not:
Agents need a new language with JSON diagnostics.
The better conclusion is:
Agentic engineering systems need structured feedback surfaces around existing languages.
If you put the structured interface in the programming language, you get a new ecosystem problem. If you put the structured interface in the lifecycle harness, you immediately improve the systems people already use.
The Correct Layer Is the Repository Lifecycle
This is why I have been building the pkt-systems-cmake-lifecycle skill for pkt.systems projects.
Not because I saw Zero and wanted to respond to it. I did not. I was already developing the skill when I stumbled over Zero from a LinkedIn post. The overlap is accidental, but instructive. Vercel and I are reacting to a similar pressure: AI agents need better operating conditions.
The divergence is where we place the solution.
Zero places it in a new language.
I place it in the repository lifecycle.
The skill codifies a complete lifecycle for pkt.systems-style C/CMake repositories:
deps -> configure -> build -> test -> hardening -> e2e -> package -> verify -> review -> release
That is not decorative process. That is the control surface.
A C project that exposes this lifecycle gives the agent a governed way to work. It can bootstrap a new component. It can migrate an existing repository. It can normalize CMake presets. It can use a Makefile as the public command surface. It can run fast tests, sanitizer tests, e2e tests, package verification, benchmark gates, fuzz smoke tests, install-tree downstream consumer tests, release archive verification, and checksum validation.
It can also stop when it should stop: API ambiguity, ABI risk, unsupported target matrix, unclear release authority, breaking artifact contract, or a version decision that cannot be inferred mechanically.
That is what agents need. They need a bounded engineering system.
C Is Not Too Primitive for Agents
There is a strange modern habit of treating C as if it were automatically hostile to AI-assisted development.
My experience points in the other direction.
C is explicit. C has a massive public corpus. C has mature compilers. C has brutal diagnostics if you turn the right knobs. C has sanitizers. C has fuzzers. C has linkers that fail loudly. C has stable ABIs. C has old scars. C has decades of boring operational knowledge encoded in tools, scripts, build systems, package managers, and deployment environments.
That is exactly the kind of terrain agents can exploit.
This is not a theoretical claim. I have already used this pattern across real C projects.
libpslog is my C structured logger. It is designed for high-performance structured logging with console and JSON output, typed structured fields, careful allocation control, fuzzing, benchmarks, and Go-vs-C comparison benchmarks. It is one of the fastest structured loggers for C I have seen, and possibly the fastest in the cases I care about. It did not get there because C needed to be replaced. It got there because the implementation was forced through a serious benchmark and verification loop.
lonejson is my schema-guided JSON library for C. It maps JSON objects directly into C structs and back again, with object-framed streaming, predictable fixed-capacity decoding, spool-backed large values, selected-array streaming, serialization from files and descriptors, and a Lua binding on top of the same core model. Again: this is not the sort of project that should survive if AI-produced C were merely bloated copy-paste sludge. It survives because the harness catches the failures that matter.
liblockdc is the C89/C90 client for lockd, my Go-based coordination substrate. It covers leases, queue deliveries, attachments, management operations, stream-based JSON and payload I/O, mTLS, HTTP/1.1 and HTTP/2 through libcurl and nghttp2, Unix socket transport, e2e environments, sanitizer builds, coverage, fuzzing, benchmarks, and cross-architecture release workflows. It is precisely the kind of C project that should be hostile to casual automation. With the right lifecycle, it becomes agent-operable.
The same idiom is now shaping unreleased work as well. Vectis is a C workflow framework for spinning up API servers with custom logic and connectivity to lockd, SFTP, and AI endpoints. CAI is an OpenAI-compatible Responses API client SDK, with extras such as MCP server handling pluggable into Kore and used by Vectis. These are not toy examples. They are the next layer of the same operating model: C components, explicit lifecycle, local verification, package discipline, and agent-friendly harnesses around the work.
The failure mode is not C itself. The failure mode is a repository where no one knows the real build command, tests only run on one laptop, e2e setup lives in a README paragraph, release artifacts are selected with a dist/* glob, benchmark regressions are vibes, and package verification means “it compiled on my machine.”
No language fixes that.
A lifecycle fixes that.
The Harness Is the Product
The pkt-systems-cmake-lifecycle skill is deliberately opinionated.
make help is the human command index. CMake presets are the configuration surface. Scripts hold stateful orchestration. Dependency roots are explicit. Generated output is treated as generated output. Release uploads come from checksum manifests, not directory globs. Binary SDK archives are verified after extraction. Installed CMake and pkg-config consumers are tested. Runtime paths are checked for relocatability. Local paths, credentials, dependency caches, sanitizer artifacts, service state, and VCS internals are forbidden in release artifacts.
This is not bureaucracy. This is how you make an agent safe enough to be useful.
The agent can move quickly because the repository is no longer a swamp. It has narrow gates and broad gates. It has fast confidence and release confidence. It has deterministic e2e where needed. It has benchmark gates where performance is part of the product. It has fuzzing when untrusted input matters. It has a release protocol that does not let the agent publish stale artifacts from the wrong commit.
That is much more valuable than a fresh syntax.
Zero Solves the Toy Version
Zero is not stupid. It recognizes something real: agents benefit from explicit effects, predictable execution, structured diagnostics, and small operational surfaces.
But creating a new systems language is the most ambitious, slowest, and least ecosystem-compatible way to pursue that idea.
A new language begins with almost no corpus, no libraries, no idioms, no battle-tested folklore, no institutional trust, no mature packaging story, and no large population of engineers who can maintain the result when the agent leaves the room.
That is a high price to pay for a cleaner control surface.
The better move is to take the languages agents already know and wrap them in a lifecycle that makes work verifiable.
That gives you the practical benefit immediately.
Agent-Native Does Not Mean Language-Native
The term “agent-native” is going to attract a lot of nonsense.
Most of it will be attempts to redesign things agents already handle well, while ignoring the operating structure around the work. That is backwards.
An agent-native C project does not need to stop being C.
It needs canonical commands. It needs reproducible builds. It needs narrow and broad test gates. It needs sanitizer and fuzzing policies. It needs e2e environments that can be started locally. It needs package verification that tests extracted artifacts, not only build trees. It needs benchmark gates where performance matters. It needs release discipline. It needs explicit escalation points for product decisions.
The language can remain boring.
The lifecycle cannot.
The Real Coordination Shift
This is a small instance of the larger coordination shift.
When AI makes implementation cheaper, the value moves to the system around implementation: intent, boundaries, verification, feedback, packaging, release control, and correctness over time.
The language is not where most organizations will fail.
They will fail because their engineering systems cannot absorb faster execution. They will give agents vague tasks inside messy repositories and then blame the model when the result is fragile. They will get more code, faster, without better control.
That is not progress. That is acceleration into entropy.
The answer is not to invent a new programming language every time the coordination layer is weak.
The answer is to make the coordination layer explicit.
For C/CMake repositories in my world, that is what pkt-systems-cmake-lifecycle is for.
It is not glamorous. It does not pretend that a new syntax will rescue software engineering. It gives the agent a governed place to stand, a set of commands to run, gates that mean something, and a release path that does not rely on hope.
That is the boring answer.
Boring is usually where the leverage is.