Discovery
Decisions made before code is written: what kind of project this is, where the model carries weight, and how much trust the work warrants.
No practices in this stage match the current filters.
-
WhenA developer or team is starting an AI-assisted coding session and deciding how much to review, validate, or version-control the output.
UseA trust posture set explicitly per project before work starts. Ask whether the project is a prototype, an internal tool, or production code touching user data, and let the answer drive how much manual review, sourcing, and validation you require. Make the regulation deliberate instead of intuitive.
EvidenceAcross 190,000 words of developer self-report (Reddit, LinkedIn, interviews), experienced practitioners already self-regulate trust contextually. They run high-trust workflows for weekend projects and prototypes and lower-trust workflows for anything involving authentication, user data, or production deployment. The practice emerged organically without industry guidance.
-
WhenYou’re scoping or reviewing a system that uses an LLM somewhere in its pipeline and you need to know how much architectural exposure that creates.
UseA “garbage-output test” before implementation. Ask: if the model returned malformed or hallucinated output right now, would the rest of the system still work correctly? If the answer is no, the LLM is load-bearing, not decorative, and needs schema validation, fallback paths, and explicit failure handling treated as core engineering work, not polish.
EvidenceTwo student-built games at the University of Calgary embedded LLMs as architectural components rather than flavor generators. Once outputs drove progression, fairness, and difficulty, model errors stopped feeling cosmetic and started reading as fairness violations. Developers reported that prompt engineering, schema enforcement, and validation pipelines were the work, not optional extras.