Stop Treating Code as the Artifact

In the old model, code was the artifact. Humans wrote it, reviewed it, and guarded it carefully because producing it was expensive. The first wave of agentic coding products leaned into this history, acting as extensions of a human operator and producing code artifacts shaped by individual taste, conventions, and review.

In the new model, the system that produces code is the artifact.

Once most code is written by agents, the codebase stops being something you defend and starts being something you continuously reshape. Files change constantly. Entire subsystems appear, disappear, and re-form. Stability does not come from freezing code in place; it comes from the constraints under which change is allowed.

This breaks a lot of inherited instincts.

Review no longer scales as the primary quality mechanism. Style guides stop mattering on their own. Line-by-line scrutiny becomes less important than whether the system makes entire classes of mistakes impossible.

Control moves elsewhere:

• from reviews to guardrails
• from style to invariants
• from individual patches to feedback loops

In practice, this means encoding taste and policy as executable constraints. Guardrails stop being documents or review comments and become tests. If a class of mistake is unacceptable, it should be impossible to merge by construction.

For example, instead of catching issues in review, I encode them as bespoke ESLint rules that enforce project-specific invariants. Not “follow this style,” but “this pattern is illegal here.” Not “please remember to handle this case,” but “this code does not compile if you forget.” The goal is not to guide agents toward good code, but to make bad code unrepresentable.

You can see the inversion clearly in Symphony, which is almost a ghost library. It ships no canonical implementation, only a specification for a service that orchestrates coding agents against issue tracker work: WORKFLOW.md as the repo-owned policy surface, typed runtime configuration, per-issue workspaces, retries, lifecycle hooks, and operator-visible observability. The expectation is not “import this package and call these functions.” The expectation is that users describe the system precisely enough that a coding agent can implement their own version inside their own environment.

That would have been a bizarre software artifact in the old world. A library that is mostly a spec would have felt incomplete, like it forgot to ship the important part. In an agentic world, the opposite is often true. The spec is the important part. If the boundaries, contracts, and invariants are sharp enough, generating the implementation is the cheap step. The durable value is the description of the system, not the particular pile of source files that happened to realize it first.

Making misaligned code impossible to write and merge is much more achievable today because agents remove throughput constraints on producing code to solve business problems.

A codebase with strong constraints and clear structure can safely absorb enormous amounts of change. A codebase without them collapses under its own output, regardless of how “good” individual patches look.

This is why asking “can the model write good code?” is the wrong question. Models will happily write both good and bad code forever.

The right questions are:

• What code is the model allowed to write?
• What patterns are illegal by construction?
• How quickly do we notice when something deviates?

Once you internalize this, quality stops being a bottleneck managed by human attention. It becomes a property of the system itself.

And systems that encode quality scale. Systems that rely on review do not.