This is a WIP community resource, containing contributions from community members.
This page is aimed at students who are beginning to use AI tools in a lightweight manner in coding projects. The examples and advice below are intended to help you use AI in a formative and instructive way: not simply to get the task done with minimal effort, but to understand the AI's suggestions, evaluate them critically, and improve your own software engineering skills.
Resources we have created for AI-assisted coding are given below:
AI tools can be used with different levels of autonomy. As a student, it is usually better to progress gradually: start by using AI to support your learning, then move to more autonomous tools only when you can still understand, review, test, and explain the result.
At every level, treat the AI as a collaborator, not a replacement. It can accelerate your work, but you are ultimately responsible for understanding, validating, testing, and explaining the final result.
At this level, AI is used to explain concepts rather than produce task-specific code. The AI does not see your codebase unless you manually describe or paste relevant details, and you still do the implementation yourself.
In practice, you can use the chat interface of an AI tool (e.g., ChatGPT, Claude, Gemini, or Microsoft Copilot) to ask AI questions. Some example questions:
null values from a Java list?This level can be especially useful when you are learning a new concept or tool, because the AI can give explanations, examples, and alternative ways of thinking about the topic without taking over the coding task.
Guidelines:
At this level, AI helps with small, bounded changes based on a selected snippet, current file, terminal output, or pasted context. You choose the context, request the change, and decide whether and how to integrate the result.
In practice, you normally use an IDE extension provided by an AI coding tool (e.g., Claude Code, Codex, Gemini, GitHub Copilot) to communicate with the AI tool more easily about the code. For example, you can select the relevant part of the code in the IDE, and use the interface provided by the IDE extension to ask the AI to make a specific change. Some examples of requests:
Unlike Level 0, the AI now sees part of the actual task context. That means some of the code may be written or rewritten by AI, so you must be able to read, explain, and validate the change before using it.
Guidelines:
Example prompt patterns:
./gradlew test and got the stack trace below. Explain the most likely cause, point to the relevant line, and suggest a minimal fix. Do not rewrite unrelated code."Parser#parse(String input) method and its JavaDoc, list important equivalence partitions and boundary cases. Then generate JUnit 5 tests for the three highest-risk cases."At this level, you work with an AI agent interactively to plan, edit multiple files, run commands, observe results, and iterate toward a specific goal. The AI may do much of the mechanical work, but you supervise it closely at each step.
In practice, you might ask an agent to add a small feature, review its plan, approve or reject edits, run tests through the agent, and ask follow-up questions when the output is unclear. This is similar to supervising a more knowledgeable assistant through a project task. Commonly used tools are either IDE extensions of AI coding tools or AI coding tools that work as standalone apps (CLI or desktop versions).
This level works best when the repository gives the agent clear instructions, such as AGENTS.md, CLAUDE.md, or tool-specific project guidance. You should still have enough knowledge to perform the task yourself, because careful supervision requires understanding the goal, the code, and the risks.
Guidelines:
At this level, you specify the desired outcome rather than the detailed steps. The agent works in the background, edits code, runs tests, and returns a reviewable artifact such as a pull request or patch.
For example, you might assign a GitHub issue to a coding agent (either running through an AI harness on your computer or in a remote environment such as GitHub) and later review the pull request (or the diff) it creates. This enables more autonomous and parallel work, but it also increases the review burden.
The student still owns acceptance of the final work. To use this level responsibly, you need strong code review, testing, and integration skills, because you may be approving code that you did not personally write.
Guidelines:
AI tools (the so-called 'vibe coding tools') can create or prototype an entire application (e.g., web apps, mobile apps) based on prompts. These tools can be useful for exploring ideas quickly, but students may not always be familiar with the frameworks, libraries, and design choices used in the generated app.
Examples:
For students, a safer default is to treat the generated app as a functional prototype rather than as the final implementation. Use it to explore requirements, UI flows, data models, and edge cases. Then rebuild the application in a more controlled way using tools and design choices you understand, so that the final code remains explainable, maintainable, and useful for learning.
If you continue from the generated code, do so only when you understand the tool stack well enough to review, test, maintain, and explain the code.
Spec-driven development uses AI tools to turn a clear specification into an implementation plan and then into code. Instead of prompting the AI to "build the feature" immediately, you first work with it to clarify requirements, acceptance criteria, design decisions, and implementation tasks.
Examples:
For students, this approach can be useful because it slows the work down in a productive way. Before code is generated, you have a chance to inspect the problem statement, refine ambiguous requirements, think through the design, and identify tests. This can make the AI-assisted work more instructive than simply asking for code directly.
The specification is not automatically correct. Review the generated requirements, design notes, and task breakdown carefully. If the spec is vague, over-engineered, or based on a misunderstanding, the resulting code is likely to inherit those problems.
Use spec-driven development iteratively, not as a waterfall process. Specify a minimal version of the product or one feature in detail, implement and review that slice, then repeat. Trying to specify an entire product and generate the complete application in one shot can produce a large amount of code that is difficult for a student to understand, test, and maintain.
It is possible to use AI tools not only as coding assistants, but also as opportunities to practice ethical judgment and critical thinking. Always follow the AI-use policy of the course you are taking, document AI assistance when required, and critically evaluate outputs before adopting them into your work.
Keep these points in mind:
Contributors: Dillon Tan (@dillontkh), Jay Hong (@hjungwoo01)