Kubernetes generated three quarters of its new API validation in v1.37

Add `+k8s:maxLength=64` and `+k8s:optional` above a `*string` field in types.go and the field is not yet guarded by anything you can read in the diff ^[14]. validation-gen reads the tag and emits the Go function that used to be typed by hand: a nil check, a length comparison, and a `field.TooLong` error at the right path ^[4][14]. The tag is the source. The function is build output.

That inverts the failure mode. A hand-written block fails where a reviewer can see it, with a wrong bound or a missing nil guard sitting in the changed lines. A tag fails by meaning something adjacent to what the author intended, or by not being wired to anything at all. The v1.37 work reads like a team that hit the second case: the stated goal was that a DV tag can no longer silently do nothing or do the wrong thing, across four enforced layers ^[9]. The first sweeps every registered strategy in the control plane so that it declaratively opts into validation ^[10]. The second requires tags gated on a strategy option to declare that option explicitly, so the gate is loud rather than silent ^[11].

The throughput figure needs reading carefully. Thirty more reviewed PRs than the previous release is a 34% rise in volume ^[1], absorbed without new capacity on the two core reviewers the post names ^[12]. The same post credits lint rules and pre-reviews by six named contributors for that result ^[12][13]. Declarative validation's share of the 34% is not separated out in any number given.

For the record to mean anything on your API surface, your review time has to have been going into validation logic in the first place. If the argument in your reviews is about field shape and defaulting, generated bound checks do not touch it. Note also what the 75% is a share of: new validations ^[5]. A quarter are still hand-written, and according to Jordan Liggitt those are the complex ones, with the straightforward rules done declaratively ^[2][15]. Of 206 DV adoptions in v1.37, 150 are purely new fields carrying no hand-written validation beside them ^[8], which leaves 56 that are something else ^[3].

The part worth copying is the guardrail Liggitt singles out: DV tags automatically require covering test cases ^[15]. That is what keeps a generated check from being an unverified assertion, and it costs a lint rule. The same discipline applies to retrofits, since existing types including PodSpec adopt DV by adding tags and corresponding tests ^[16]. A generator does not get sloppy at field 300, which is the whole case for moving validation into the type definition; the case holds only while something forces the tests to exist.