AI Examples & Checklists
This page is a reference for situations where you are unsure whether a particular use of AI is appropriate.
You do not need to memorize every example. Use the sections relevant to the assessment you are currently working on.
Assignments
For assignments, remember the core principle:
Practice First, AI Second.
The goal is to use AI to support your own attempt — not to replace the implementation and debugging practice that the assignment is designed to provide.
Appropriate Uses
These are generally appropriate:
“What does this error message mean?”
Good: you are asking for clarification about a specific problem.
“Here is the code I wrote. Why might this request be returning 404?”
Good: you have attempted the implementation and are asking for targeted debugging help.
“Can you show me a small example of how this API works?”
Usually appropriate if the example helps you understand the API rather than replacing the assignment implementation.
“What edge cases should I test for this function?”
Good: AI is helping you evaluate your own implementation.
“Why does this state update behave differently from what I expected?”
Good: you are using AI to understand behavior you encountered while working through the task.
Too Much Delegation
These uses bypass too much of the intended practice:
“Here is the assignment handout. Solve it.”
Not appropriate.
“Read these requirements and design the complete implementation for me.”
Not appropriate.
“Generate all files necessary to complete the assignment.”
Not appropriate.
“Write all the code needed to pass these tests.”
Not appropriate.
“Generate the full solution first and then explain how it works.”
This still bypasses the implementation practice the assignment is designed to provide.
Assignment Checklist
Before asking AI for implementation-specific assistance, ask yourself:
- Have I read and understood the relevant requirement myself?
- Do I know what concept or technical skill this part is intended to practice?
- Have I thought about how I would approach it?
- Have I made a genuine attempt where appropriate?
- Can I identify the specific issue I now want help with?
If most answers are yes, your AI request is probably appropriately scoped.
If not, make the question smaller or return to lecture material, documentation, Piazza, or office hours first.
reasoning.md: Specific vs. Generic
The goal of reasoning.md is not polished writing. It is to provide brief, task-specific evidence of engagement.
Q1
Too generic:
I thought input validation would be difficult.
More useful:
I expected the validation logic for
POST /api/papersto require careful handling because the API needs to detect multiple missing or invalid fields and return all applicable validation messages together.
The second response identifies a specific technical concern from the assignment rather than naming a broad topic.
AI-assisted debugging
Too generic:
I used AI for debugging.
More useful:
My
GET /api/papersendpoint was acceptinglimit=10.5instead of returning a validation error. AI helped me identify that my number conversion was accepting partially valid numeric input. I changed the validation logic and tested valid integers, decimal values, and non-numeric values to confirm the required behavior.
Remember that debugging assistance counts as AI use. If AI helped identify or explain a bug, describe one specific example, what you did with that input, and how you verified the result.
Course Project
For the course project, AI may contribute more substantially because the learning goals emphasize system design, integration, technical judgment, and verification.
The core workflow is:
Think → Explore → Evaluate → Decide → Implement → Verify
AI can contribute throughout this process, but your team remains responsible for understanding, evaluating, and verifying the resulting work.
Exploring Technical Options
Appropriate:
“We are considering SQLite and PostgreSQL for our project. What technical tradeoffs should we investigate before choosing between them?”
AI can help surface relevant considerations.
Your team should then determine which considerations actually matter for your project and make the final decision.
Less appropriate:
“Choose the best database for our project and design the database architecture.”
This delegates both the investigation and the decision before the team has developed its own technical judgment.
Architecture and Technical Decisions
Weak process:
AI recommended Next.js because it is easier for full-stack development, so we chose Next.js.
Stronger process:
AI suggested a Next.js full-stack architecture because our frontend and server logic would be developed in the same codebase. We compared this with a separate React + Express architecture and considered how each option would affect API design, team coordination, and frontend–backend integration. We chose Next.js because our application did not require an independently deployed backend, and keeping the major application layers together reduced integration overhead for our team.
The difference is not that the second answer is longer. It shows that the team evaluated the recommendation, considered an alternative, and made its own decision.
Generated Code or Configuration
Weak process:
AI generated our cloud storage upload code and it worked, so we used it.
Stronger process:
AI generated an initial implementation for uploading files to our cloud storage service. We reviewed how credentials, object keys, and database records were handled, changed the implementation so that stored files were associated with the correct application records, and tested upload and download using several files. We also verified that the database and storage remained consistent after deleting or replacing a file.
Generated work can be useful, but working output alone is not sufficient evidence that the team understands or has verified it.
Debugging
Weak:
AI fixed the problem with our frontend not updating after a database change.
Stronger:
AI suggested that the stale UI was caused by the client state not being updated after the server-side mutation completed. We traced the request and response flow, confirmed that the database update was succeeding, and found that the frontend was still rendering old state. We changed the update logic and then tested the full user flow to confirm that both the persisted database state and the visible UI changed consistently.
Again, the important part is what your team did after receiving the AI input.
Project Design Checklist
When AI meaningfully influences a technical decision or implementation, discuss questions such as:
- Does this suggestion actually satisfy our project requirements?
- What assumptions does it make?
- Do we understand why it should work?
- Are there reasonable alternatives we should consider?
- What are the relevant tradeoffs or limitations?
- Can we verify important technical claims using documentation, testing, or experiments?
- Can the team explain and defend the resulting decision?
These are prompts for your own reasoning and team discussion, not simply questions to send back to AI.
ai-session.md: Choosing Good Evidence
Good ai-session.md examples usually involve a moment where your team had to think after the AI responded.
Useful examples include:
- AI made a technically incorrect suggestion
- AI surfaced an alternative that changed your approach
- Your team rejected an AI recommendation
- Generated code or configuration required meaningful modification
- A technical claim was checked against documentation
- An implementation was validated through testing, logs, or monitoring
Less useful examples include:
- Routine wording edits
- Simple syntax completion
- Trivial factual questions
- Large copied AI responses with little explanation of what the team did afterward
The goal is not to show that you used AI frequently. It is to provide representative evidence of technical judgment, correction, and verification.
If your team genuinely used little or no AI, simply state this clearly. You are not expected to create or exaggerate AI interactions for the purpose of this requirement.
Choosing the Right Granularity (Task Size)
The appropriate granularity, or task size, of AI assistance differs between assignments and the project, but the same general principle applies:
More substantial AI involvement calls for correspondingly stronger understanding, evaluation, and verification.
Smaller Tasks
Examples include:
- Explaining one API
- Diagnosing one error
- Generating a small helper function
- Producing one configuration fragment
- Suggesting tests for one behavior
These are usually easier to inspect and verify.
Larger Tasks
Examples include:
- Implementing a substantial feature
- Designing a storage approach
- Refactoring several interacting components
- Producing a significant subsystem
- Generating a deployment configuration
These may be reasonable in the course project, but they require correspondingly stronger review, testing, and explanation.
For assignments, tasks of this size usually delegate too much of the intended learning activity.
If you cannot reasonably understand, explain, and verify what AI produced, the delegated task was too large.
Verification
AI-assisted work should be verified to a level appropriate to its scope and significance.
Depending on the situation, verification may include:
- Careful code review
- Running provided tests
- Writing additional tests
- Functional testing
- Inspecting logs
- Reading official documentation
- Controlled experiments
- Comparing behavior with expected results
A small syntax suggestion may require only careful review.
A larger component, architectural recommendation, generated configuration, or important technical claim may require stronger evidence.
Do not assume something is correct simply because it looks plausible, sounds confident, or appears to work once.
When in Doubt
For an assignment:
Do more of the core work yourself and make the AI request smaller.
For the course project:
Use AI where it is useful, but evaluate the input, make the decision yourselves, and verify what you rely on.
Across both:
Practice what you need to learn. Understand what you submit. Verify what AI contributes.