For 20 years, Charles Bryant optimized his typing speed, memorized APIs, and pushed himself to write code faster. Now he writes zero lines of production code and says he's more productive than ever.
Bryant, a self-taught developer who built payment systems processing billions of dollars monthly, calls himself a "0x coder" - someone who produces no code personally but directs AI agents that do. His argument, laid out in a detailed essay, is that the programming industry has been optimizing for the wrong skill all along.
The Shift from Typing to Judgment
Bryant's workflow looks nothing like traditional development. Instead of opening an editor and writing functions, he follows an eight-step process: define the intent, specify contracts (input/output rules and constraints the code must follow), write tests before any implementation exists, then hand the scoped workspace to an AI agent. The agent scaffolds, implements, and refactors. Bryant reviews outcomes rather than reading code line by line.
He claims full service scaffolding now takes minutes instead of days.
The framework he describes, which he calls "AgenticOps," has four containment rings: constrain inputs, constrain the environment, validate outputs, and gate promotion to production. The idea is that you don't need to trust the AI's code if you've boxed it in tightly enough with tests, contracts, and automated evaluation.
Where This Argument Holds Up
For CRUD applications (create, read, update, delete - the basic database operations that make up most business software), Bryant has a point. A huge percentage of production code is repetitive plumbing: API endpoints, database queries, form validation, data transformation. These are exactly the tasks where AI coding assistants like Cursor, Claude Code, and Cody already perform well.
Bryant's background matters here too. He spent two decades developing the system design and constraint-definition skills that make his agent-governed approach work. He's not a junior developer asking ChatGPT to build an app from a vague prompt. He's an experienced architect who replaced the typing part while keeping the thinking part.
Where It Gets Shaky
Bryant admits something important: "I've never fully understood the systems I work in. AI made that worse, but containment made it manageable." That's an honest acknowledgment, but it's also a warning.
Containment works until it doesn't. Payment systems, which Bryant specifically has experience with, have edge cases that no test suite fully covers. The developer who doesn't read the code is trusting their test harness to catch everything, and test coverage is a measure of what you thought to test, not what can go wrong.
There's also a selection bias in the essay. Bryant is describing greenfield development (building new systems from scratch) with a single developer. The dynamics change significantly in large codebases with multiple contributors, legacy constraints, and production incidents that require reading and understanding existing code quickly.
The Useful Middle Ground
The most practical lesson isn't "stop writing code." It's that the highest-value developer skills have shifted. System design, problem decomposition, constraint specification, and output evaluation matter more now than raw coding speed. Tools like Cursor, Claude Code, Aider, and Continue are making the implementation layer cheaper every month.
Bryant's extreme position makes for a compelling essay. The realistic version is less dramatic but still important: spend less time typing, more time thinking, and get comfortable reviewing AI output critically rather than writing everything yourself.