Why it matters: Engineers who brief language models the way they brief junior staff get confident, well-formatted answers aimed at the wrong target, and the error stays hidden until something breaks in production.
The Details:
- A compiler halts on ambiguity and hands you an error you can fix on the spot. A language model does the opposite: underspecified intent still produces code that compiles, reads cleanly, and runs, so the mistake surfaces later as a failed test or an angry customer rather than as an immediate stop.
- The habit that makes senior engineers effective with people, handing off a vague goal and trusting judgment to fill the gaps, works against them here. A model has no accumulated context about your system, your risk tolerance, or what "done" means, so it fills gaps with generic plausibility instead of your actual intent.
- Prompts that succeed name what already exists, what the goal is, and what to avoid before asking for output. Pointing at a failing test, a stack trace, or a type signature gives the model something concrete to be wrong against, which functions as the feedback loop a compiler gives you automatically.
- Asking a model to "review this diff" yields generic style notes; asking it to check locking behavior under concurrent writes yields something useful, because the targeting, not the model's raw capability, decided the value of the answer. The same gap shows up outside code, in memos, reports, or any output where constraints were left unstated.
Bottom Line: The skill of experienced engineers has not disappeared, it moved upstream into writing the specification instead of trusting the model to infer one.
