Add section on Vibecoding and AI/LLM

CONTRIBUTING.md

@@ -25,8 +25,10 @@ will be closed. We need to ensure the code we're adding to master is written to
 ## Expedited Module Creation Process
 We strive to respect the community that has given us so much, so in the odd situation where we get multiple submissions for the same vulnerability, generally we will work with the first person who assigns themselves to the issue or the first person that submits a good-faith PR.  A good-faith PR might not even work, but it will show that the author is working their way toward a solution.  Despite this general rule, there are rare circumstances where we may ask a contributor to step aside or allow a committer to take the lead on the creation of a new module if a complete and working module with documents has not already been submitted.  This kind of expedited module creation process comes up infrequently, and usually it involves high-profile or high priority modules that we have marked internally as time-critical: think KEV list, active exploitation campaigns, CISA announcements, etc.  In those cases, we may ask a contributor that is assigned to the issue or who has submitted an incomplete module to allow a committer to take over an issue or a module PR in the interest of getting a module out quickly.  If a contributor has submitted an incomplete module, they will remain as a co-author of the module and we may build directly onto the PR they submitted, leaving the original commits in the tree.  We sincerely hope that the original author will remain involved in this expedited module creation process.  We would appreciate testing, critiquing, and any assistance that can be offered.  If the module is complete but requires minor changes, we may ask the contributor to allow us to take over testing/verification and make these minor changes without asking so we can land the module as quickly as possible.  In these cases of minor code changes, the authorship of the module will remain unchanged.  We hope everyone involved in this expedited module creation process continues to feel valued and appreciated.
 
-### Code Contribution Do's & Don'ts:
+## Vibecoding, AI, and LLM
+My first job had a token ring LAN and I still own a Win98SE CD, so I'm not entirely sure what _vibecoding_ is, but we're cool with any coding technique you use to create a PR as long as it is tested, documented, and does what it says it does.  Untested code is incomplete code, and incomplete code should be marked as a draft PR or WIP (Work in Progress) until it is complete, tested, and ready for a committer to review.  We have had several sumbissions clearly from AI that were well-formatted, looked really neat, and did nothing it said it did.  While we have no problem with AI-assisted coding, please do not assume that the code generated by an AI or LLM is logically or even syntactically correct.
 
+### Code Contribution Do's & Don'ts:
 Keeping the following in mind gives your contribution the best chance of landing!
 
 #### <u>Pull Requests</u>
@@ -42,7 +44,7 @@ Keeping the following in mind gives your contribution the best chance of landing
 * **Do** target your pull request to the **master branch**.
 * **Do** specify a descriptive title to make searching for your pull request easier.
 * **Do** include [console output], especially for effects that can be witnessed in the  `msfconsole`.
-* **Do** test your code.
+* **Do** test your code and submit the test output in your PR with any sensitive information removed.
 * **Do** list [verification steps] so committers can test your code.
 * **Do** [reference associated issues] in your pull request description.
 * **Don't** leave your pull request description blank.