# AI Generates Faster Than You Review. Properties Replace the Reviewer. > Source: > Published: 2026-08-17 13:21:28+00:00 ✓ Human-authored analysis; AI used for formatting and proofreading. The pull request model worked for twenty years because both sides of the review had the same thing: domain knowledge. The author and the reviewer understood the codebase. The review was a conversation between two experts. AI broke that assumption. The author is now a machine that doesn't understand the codebase. It lacks company specific business logic spread across different applications, spreadsheets, docs, confluence, wikis, emails and slack threads. The reviewer must now supply ALL the domain knowledge. Reviewers must verify that the generated code fits the architecture, follows conventions, aligns with the domain knowledge, respects invariants nobody wrote down, and doesn't introduce subtle design violations that pass every test. Review became harder than writing. This doesn't scale. AI agents generate large number of commits in a day. The reviewer is the same person, with the same finite attention, reading diffs at human speed. The options are: Slow down the agents (defeats the purpose), rubber-stamp the PRs (accepts the risk), or find something that replaces review. The instinct is to write better documents. GitHub's Spec Kit crossed 120k stars on this idea: define what to build before building it. The spec becomes the input to the AI agent that generates the code. This is a better prompt, not a solution. The spec tells the AI what to generate. Nothing tells anyone whether the generated code satisfies the spec. The verification step is missing. A spec written in natural language can't be mechanically verified. It can only be read by another human, which puts you back at the review bottleneck. Specifications have failed before. Rational Rose generated code from UML diagrams. The diagrams were wrong. The generated code faithfully implemented the wrong design. The problem wasn't the tool. The problem was that a natural-language document that is structured and detailed requires human interpretation. Two humans interpret it differently. Neither can verify it mechanically. Properties are different. A property is a statement that is true or false, checkable by a machine, with no room for interpretation. "Every stateful resource must be encrypted at rest" is a property. For any resource, the answer is yes or no. There is no "it depends." There is no ambiguity about what "encrypted at rest" means. The resource either has encryption enabled or it doesn't. A machine checks it. Same answer every time. "The system shall protect data using industry-standard encryption" is a specification. It requires a human to decide what industry-standard means, which data is covered, and whether the implementation qualifies. That human is the reviewer. The reviewer is the bottleneck. The difference matters because properties can replace the reviewer. Specifications cannot. The replacement comes from a discipline that predates software by decades. Systems Engineering is the field that builds nuclear plants, spacecraft, and medical devices. It separates properties from implementations and verifies mechanically that the implementation satisfies the properties. The human writes the properties. The implementation by a human, AI or bot is verified against the properties mechanically. The properties don't generate the code. No reviewer in the loop. The model has two sides. The left side is human work, done once. The right side is machine work, done continuously: ``` HUMAN (once) MACHINE (continuous) Write 30 properties Verify implementations │ ▲ ▼ │ Define domain Find gaps in coverage (which services apply) (properties reveal missing controls) │ ▲ ▼ │ Create templates Systematic fault-finding (how a property instantiates) (structured guidewords on every component) │ ▲ ▼ │ AI generates 4,500 controls → Verify each control fires correctly ``` The human's effort is on the left side only. Each step on the right side corresponds to a step on the left, verifying at the same level. The machine generates, verifies, finds gaps, and catches bugs. This is continuous, at any scale, without a reviewer. In cloud security, the universal statements look like: "Every stateful resource must be encrypted at rest." Boolean. Checkable. No interpretation. "No principal should have unrestricted Permissions Management actions." Boolean. Checkable. No interpretation. "Credentials must rotate within their scheduled lifetime." Boolean. Checkable. No interpretation. Each universal statement generates specific properties for every service in its domain. The encryption statement generates a property for S3, a property for RDS, a property for DynamoDB and so on. One for every service that stores data. 30 universal statements. 4,500 properties derived from them. There are about 30 universal statements. Each applies across every service in its domain, generating hundreds of specific properties. A domain expert can audit all 30 in a day and by auditing 30, they've covered the 4,500 properties that derive from them." They change slowly only when understanding of the domain deepens, not when AWS adds a new service. The implementation is 4,500+ controls that instantiate these 30 properties across 121 AWS services. Each control checks one property on one resource type. These change constantly when every new service needs new controls. AI generates them from the properties. The verification runs in both directions. Downward: does every control follow from a property? If a control fires and no property covers it, the control is wrong. Upward: does every property cover every service in its domain? If the encryption property applies to 35 stateful services and the catalog has controls for 27, the other 8 are gaps found mechanically, not through incidents. No human reviews 4,500 controls. A human reviews 30 properties. The machine does the rest. The PR model puts domain knowledge in the review step. The reviewer must understand each implementation well enough to judge its correctness. When one agent generates code, one reviewer keeps pace. When ten agents generate code, the reviewer falls behind. When a thousand agents generate code, the model collapses. Properties put domain knowledge in a mechanically verifiable artifact. The expert writes 30 properties. The verification is mechanical. Does the implementation satisfy the property? A machine answers this question at any scale. One agent generating code: 30 properties, one verification pass, human reviews 30 properties. Ten agents: 30 properties (unchanged), ten verification passes (automated), human still reviews 30 properties. A thousand agents: 30 properties (still unchanged), a thousand verification passes (automated), human still reviews 30 properties. The properties are constant with respect to the number of agents. The verification scales linearly but is automated. The human effort doesn't grow. Does this work? We ran the cycle on cloud security. 30 universal properties generated 4,500+ controls across 121 AWS services. After the AI generated a batch of 37 controls from one template, we applied a systematic fault-finding methodology from chemical process safety, adapted for software. Six structured guidewords applied to every component, looking for deviations from the intended behavior. The analysis found 5 silent false negatives. Five controls had wrong identifiers. They existed in the catalog, appeared correct in every dashboard, but never matched real data. They would have sat there for months, making 5 services appear secure when they weren't. A human reviewer would have needed to read each control, understand the data schema for that service, and verify the identifier matched. This is a multi-day review across 37 services. The systematic fault-finding found all 5 in one pass. Automated. Systematic. Fixed in one commit. The cycle validates itself. The properties found 51 gaps in the catalog. The services where the property should hold but no control existed. The machine authored 51 controls to close them. The analysis found 5 were silently broken. The fix went in. Without the systematic fault-finding step, 5 controls sit in the catalog, 5 services appear clean, 5 silent false negatives surface months later when an incident reveals the control didn't fire. This approach works well in cybersecurity because of two characteristics. First, the properties are clear. "Encrypted at rest" is boolean. "Authentication required" is boolean. There's no subjective judgment. Other domains have fuzzier properties such as "the UI should be responsive" or "the code should be readable" that resist formalization. Second, the verification is decidable. Given a configuration and a security property, the answer is yes, no, or can't tell (with a classification of why). There's no "maybe it's secure depending on context." The verification terminates with a definitive answer. These two characteristics made cybersecurity the proving ground. But the structure doesn't require them. It requires only that properties can be written by domain experts, implementations can be generated by machines, and verification can compare the two. For API development, the properties are "every endpoint requires authentication" and "every response includes rate limit headers." The AI generates endpoint handlers. The verification checks handlers against properties. For data engineering, the properties are "no null in required fields" and "referential integrity across tables." The AI generates pipeline transformations. The verification checks outputs against properties. For infrastructure as code, the properties are "all subnets have route tables" and "no hardcoded credentials in any Terraform file." The AI generates modules. The verification checks plans against properties. The pattern is the same. The property constrains. The machine generates. The verification confirms. The human writes properties, not reviews. Kent Beck captured the same insight in 1997 with JUnit: "write the test once, execute it mechanically forever." The human writes the test. The machine runs it. The test is the domain knowledge, extracted from the developer's head into an artifact that the machine can check without the developer being present. Properties are Beck's insight scaled to the agentic era. Write the property once. Verify implementations against it mechanically forever. The property is the domain knowledge, extracted from the expert's head into an artifact that the machine can check at any scale. Beck made the developer's judgment reusable across test runs. Properties make the expert's judgment reusable across agents, implementations and the entire development lifecycle. The judgment is in the artifact. The verification is in the machine. The PR is obsolete. *The cycle described in this article properties, generation, verification, systematic fault-finding and gap sweep is implemented in Stave, an open-source AWS configuration verifier. 30 universal properties. 4,500+ controls. 121 services. The property is the review.*