Explicit vs. Implicit Logic: A Paradigm Sketch for Software Engineering in the AI Era
This article started with the most ordinary production incident: AI-generated code passed CI but couldn’t survive production.
Starting from that frustration, I tried to think the problem through clearly.
If something works correctly in every verifiable environment, then it’s correct. If it can withstand the test of a real production environment, then it can be used in real production.
Throw a crude version of TikTok into a sandbox. Validate it continuously with real production data—HTTP requests, security tests, real observability metrics constraining its behavior. Let it continuously update code, config, and data within a minimal independent unit. Eventually, you get an AI capable of building the real thing.
Explicit Logic vs. Implicit Logic
From an information-theoretic perspective, the logic of any industrial-grade software system comprises two parts: explicit logic and implicit logic.
Explicit Logic: the stuff AI can easily read and learn. Requirement docs, API definitions, coding standards, test cases—anything you can write down and put into a training set. That’s explicit logic.
Implicit Logic: constraints that are hard to fully capture in documentation, yet determine whether a system can remain stable under real load and complex timing conditions. They form the basis for stability in complex systems, manifesting in two dimensions:
- Architectural Design Philosophy: high-level design intent typically held only by core developers, whose knowledge transfer involves extreme information loss and communication overhead.
- Boundary Constraint Behaviors: rarely documented in specifications, these typically exist as patches for historical anomalies or defensive code (e.g., adaptive rate limiting, flexible compensation under distributed network partitions, exponential backoff retries). As systems scale, this kind of logic expands rapidly, representing a form of “necessary redundancy”—without it, cascading failures or even system collapse become likely; over-defining it, meanwhile, drives up complexity entropy.
The Limitation of AI Coding
Current AI training is essentially a grand ceremony of explicit logic infusion—an extension of the traditional “requirement → code” path. We teach AI to write “seemingly correct” code using massive volumes of requirement docs, Q&A pairs, and code snippets. Then we evaluate it with an explicit-logic ruler: does the code run? Any syntax errors? Does it match the spec?
But that ruler can’t measure implicit logic.
Today’s AI doesn’t know what memory fragmentation is. Doesn’t know what connection pool exhaustion looks like. Doesn’t know about cold-start latency spikes. Because none of that knowledge exists in the training data. It lives in every production alert, in every “I don’t know why, but restarting it fixed it” moment.
This is why you can have AI generate an entire codebase that passes in the test environment, only to watch it collapse the moment it hits production.
An Engineer’s Deduction Chain
AI needs to learn rules to generate correct output.
- Rules come in two kinds: those you can write down (explicit logic), and those that can only manifest at runtime (implicit logic).
- Current AI training almost exclusively feeds explicit logic.
- Explicit logic hits diminishing returns past a certain point. Because what determines production survival is implicit logic.
- Implicit logic exists almost exclusively in production environments.
- Therefore, the future of AI training must involve turning production into a continuous data stream that AI can perceive and learn from.
- This means bridging code authoring and production operations. In the AI-native era, developer and operator must become one.
- If AI can develop stronger capability simply by engaging with continuous data from production, then perhaps we have been constrained all along by the “requirement → code” mental model. Human requirements are themselves a lossy, lower-dimensional expression; they may never fully cover the minimal logic demanded by the real world. By contrast, letting AI fit directly against real-world feedback may be a more direct path toward the requirement itself.
What This Unlocks
- The ultimate form of DevOps—the ideal runtime for software engineering. Development, testing, deployment, and monitoring are no longer separate phases but a single continuous feedback loop.
- Eliminates distribution shift between “training set” and “real world.” The data AI trains on is production data—there is no “trained fine, broke in prod” problem.
- No extra context plumbing needed. The production environment (a massive container-based AI orchestration platform) is itself a unified context—all metrics and data available on demand.
- AI learns within the container platform, and implicit logic emerges continuously.
- Solves the high-quality data collection problem in AI training—clear inputs/outputs, clear observability metrics. AI-generated code iterates through metric feedback loops, solving implicit logic problems until reaching production-grade quality.
- The production environments of engineers and researchers converge. The same container platform serves as both the engineer’s runtime and the researcher’s lab.
- Software engineering becomes a continuously self-evolving entity.
A Path Forward
The vision above is compelling, but the challenges remain significant. However, they are fundamentally engineering architecture problems at the compute and infrastructure level—not theoretical dead ends.
The overall approach is a data-driven closed loop: production traffic is recorded and cached, then replayed into an AI sandbox that mirrors the production topology; AI generates code and runs it inside the sandbox; the observability platform continuously collects behavioral metrics (latency, error rates, resource utilization, etc.) and compares them against the real project’s baseline; deviations form a reward signal that drives AI to iterate on the code. This cycle runs continuously until the sandbox’s behavioral metrics converge to production-grade standards.
In the traditional development era, this paradigm lacked the engineering foundations needed to be practical. But in today’s cloud-native era, many of the key pain points have been eased. The infrastructure each stage depends on—observability platforms (OpenTelemetry, SkyWalking), traffic recording/replay (GoReplay, Sharingan), container orchestration and lightweight VMs (Kubernetes, Firecracker), and reinforcement learning frameworks (RLHF/GRPO pipelines)—already has fairly mature industrial practice behind it. Individual technologies are no longer the core obstacle; the real difficulty lies in integrating them in a way that is both cost-effective and secure.
Drawing on the self-play approach of AlphaZero, I propose a Shadow Evolution Paradigm as an attempt at a solution.
Shadow Evolution Paradigm
The core idea is simple: build AI a sandbox that mirrors the production topology, and let it live, learn, and evolve inside.
Concretely, the AI sandbox shares the same container infrastructure as the real project—same network topology, same resource constraints, same observability collection. AI is given only explicit logic, generates a first version of the code, and deploys it into the sandbox. Then, recorded production traffic is replayed into the sandbox, and the observability platform compares behavioral differences in real time—latency distributions, error rates, throughput, resource consumption—these deviations form the reward signal that drives AI to iterate on the code.
This process runs continuously: AI keeps modifying code, configuration, and data; the sandbox’s behavioral metrics gradually converge toward the production baseline. When the two sets of observability metrics converge within an acceptable threshold, the code in the sandbox is production-grade. Throughout this process, nobody explicitly taught AI how to handle connection pool exhaustion or how to implement cascading circuit breakers—that implicit logic evolved on its own from production data feedback.
A Final Note
Looking back, this article really began with an ordinary production incident: AI-generated code passed CI but couldn’t survive production.
Starting from that incident, I tried to think the problem through. That led to the concept of “explicit logic” and “implicit logic.” That led to the deduction chain. That led to a conjecture about the future of AI training and the next generation of software engineering.
To truly validate this paradigm, you would need a production-mirrored environment, real traffic, and complete observability and security-isolation infrastructure. That scale of engineering effort is already far beyond what an ordinary lab can carry.
But the direction it points to is already clear enough: let production become AI’s interface to the real world.