The largest tenant on the platform I work on is 613 resources described by a 10,000-line main.tf. Nobody typed any of it. A customer draws their backend on a canvas, a generator turns that into HCL, and CI applies it into the customer’s own cloud project.
I wrote the template layer that emits it, and the scaffold layer every tenant repository is built from. Which means I spent a long time doing code review wrong before I noticed the unit had changed.
216 bindings is not 216 decisions
That tenant carries 216 IAM bindings. For a while I read those the way you read hand-written config, one at a time, asking whether each looked right.
That is the wrong question. There are not 216 decisions in that file. There is one decision, about how a service relationship becomes a binding, emitted 216 times. The number is not a choice, it is an emission.
Once you see that, the review changes shape. Reading the output tells you whether the emission ran. It does not tell you whether the decision was correct, and the decision is the only part that can be wrong in an interesting way.
Uniformity reads as correctness
This is the part that made me miss things.
Hand-written code fails in scattered, individual ways. One function is sloppy, another is fine, a third has a typo. Variety is the signal, and a reviewer’s eye is tuned to it: the odd line stands out.
Generated code has no odd lines. Every instance is built the same way, so a defect appears identically in all of them. Nothing stands out, because the thing that would stand out is the thing that is uniformly wrong. Consistency looks like care, and a reviewer scrolling 10,000 uniform lines gets a strong, false impression that someone thought about each one.
The compensating habit is boring and it works: stop reading the output for correctness. Read the output to confirm the shape you expected came out, and take every actual correctness question upstream to the thing that emitted it.
The diff that matters is the small one
The practical version of this is which diff you open.
When the template changes, the generated output changes in hundreds of places. Reviewing that output diff line by line is theater. It is enormous, it is mechanical, and by line 200 the reviewer is pattern-matching rather than thinking.
The template diff is small enough to actually reason about, and it is where the change lives. So the review is: read the template change closely, form a prediction about what the output should now look like, then spot-check the output against that prediction. If the output surprises you, that is the finding. If it matches, the large diff needed no line-by-line pass at all.
The blast radius runs the same way. A defect in one generated instance is one incident. A defect in the template is every instance, in every tenant, including the ones nobody has looked at yet. That asymmetry is the whole argument for where the attention goes.
Valid is not running
There is a failure mode that template review alone will not catch, and it cost me an afternoon to understand.
The generator once emitted a service that referenced a container image by digest. The HCL was valid. The template was right. The plan was clean. The apply created the service, and the service could not start, because the image did not exist yet.
Nothing in the config was wrong. The ordering was. Declared state and running state had diverged, and every check I had was a check on the declaration.
So the gate cannot only ask whether the config is valid. It has to ask whether the thing described is actually there. That is a different question, it needs a different check, and it is the check most pipelines skip because the config already passed and passing feels like done.
The same shape now applies to code a model writes
I built these habits around a deterministic generator. They transferred directly the moment a model started writing part of every diff, because the structure is identical.
When a model authors code, the template is no longer a file of HCL. It is the prompt, the conventions the repository teaches by example, and the gate the output has to clear. Those are what multiply. A convention you fix once propagates into every future diff. A convention you leave broken ships in every future diff, uniformly, and it will read as consistent while it does it.
Which reorders what is worth your time on an AI-assisted codebase:
The individual generated diff is cheap to fix and cheap to regenerate. It is not where the leverage is. The prompt, the conventions file, and the verification gate are the artifacts with compounding effects, and they are usually the least-reviewed files in the repository.
And the reviewer’s job stops being “read every line” the moment reading every line becomes possible to fake. It becomes: decide what the output must satisfy, build something that checks it mechanically, and spend the human attention on the small upstream diff where judgment actually applies.
What I would tell someone building this
Find the emission point before you review the output. If the file was generated, the question “does this line look right” has no useful answer. Ask what produced it, and review that.
Distrust uniformity. In hand-written code the odd line is the bug. In generated code the bug is uniform, so a clean-looking file is weak evidence. Consistency tells you the generator ran, not that it was right.
Predict, then spot-check. Read the small diff, say out loud what the large diff should now contain, and check a few instances against that. Surprise is the finding. This is faster than a full pass and it catches more.
Check running state, not just declared state. A valid config that describes something which does not exist will pass every static check you own. The digest that pointed at a missing image was valid HCL right up to the moment the service failed to boot.
Treat the prompt and the conventions as production code. When a model writes the diffs, those files are the template. They get the review that the generated output no longer needs, because they are the only place a defect can multiply.