| There is an acute lack of agency here LLMs telling you to do something, when we know that they hallucinate, in no way frees you from the responsibility that you have to do your own due diligence. Take a lesson from defense & space and adopt a TRL mindset towards LLM advice in verifying… TRL 1: You’ve got a basic idea for a new software feature or tool, backed by some research. It’s just a spark, like reading about a new algorithm and thinking it could solve a problem. TRL 2: You sketch out how the idea could work in an app or system, but it’s still on paper or a whiteboard—no code yet, just a rough plan. TRL 3: You write some experimental code or a small script in a test environment to see if the core idea holds up, like a proof-of-concept for a new feature. TRL 4: You build and test individual pieces of the software (like modules or functions) in a controlled setting, ensuring they work together in a lab-like environment. TRL 5: Your code is tested in a setup that feels closer to the real world, like running it on a staging server with simulated user data. TRL 6: You’ve got a working prototype of the software that runs in a realistic environment, like a beta version tested with actual user workflows. TRL 7: The software is nearly complete and tested in a real-world-like setting, such as a pilot project with actual users or live data. TRL 8: The software is fully built, tested, and debugged, ready to be deployed to production after passing all checks, like a release candidate. TRL 9: The software is live, running successfully in production, and reliably handling real users or tasks, like a fully launched app. Generic advice: Verify with primary sources Ensure features exist before payment Cross-check examples Expect LLM errors Consider prompt & context engineering |