We see the same mistake every batch. A student gets access to an AI coding assistant, and within a week they've pasted an entire legacy codebase into the chat and asked for a rewrite. The response is a wall of plausible-looking TypeScript. It doesn't compile. They spend the next two days debugging code they didn't write and don't understand.
That's not a workflow. That's a panic move.
The useful question is smaller: where does AI fit into the boring, daily rhythm of writing and reviewing code? We've been teaching this long enough to see what survives contact with real projects. Three practices keep coming up, in every cohort, regardless of language or framework.
Write a prompt like you're leaving a code review comment
The first practice is about the quality of the request itself. Most people write prompts the way they'd ask a friend for help: "fix my bug" or "make this faster." These produce vague output because the model has no context. It doesn't know your variable names, your error messages, or the constraints you're working under.
The fix is to treat a prompt as a code review comment. When you leave a comment for a teammate, you describe the symptom, what you tried, and what you expect. Do the same for the model.
Here's a concrete example from a student project last month. She had a function that parsed date strings, and it failed on one particular format. Her first prompt was:
Why doesn't this work?
The model gave her a generic lecture about timezone handling. The second version was specific:
This function parses API dates. It handles "2024-01-15" but throws on "2024-01-15T10:30:00Z". I need the ISO 8601 format to work. Here is the function:
[function body]
What is the specific failure and what conditions cause it?
The response pointed to a single line: she was splitting on " " instead of checking for the T separator. One fix, not a rewrite.
The habit that works is to write the prompt as if you're filing a bug report. Include the input, the expected output, the actual output, and any error text. That's four sentences of context, and it changes the quality of the answer more than any model switch.
Use AI to review your tests, not to write them
The second practice is counterintuitive. Students usually want the AI to generate test cases. That's easy and it feels productive, but the tests it writes tend to mirror the implementation's assumptions. If your function sorts a list but doesn't handle nulls, the AI will write a test that sorts a list and skips the null case, because the code itself doesn't show it.
The better use is the reverse. Write your own tests first, even simple ones, then ask the AI to critique them. Give it the function and your test file, and ask: "What edge cases am I missing? Which of my tests are redundant? Is there an assertion that's too weak?"
We tried this in a class exercise with a small banking module. One student had written five tests for a transfer method. The AI pointed out that none of them covered what happens when the source account has insufficient funds, and that one test asserted the balance changed but not by the right amount. Both were true. The student hadn't written those tests because she assumed the happy path was enough.
The reason this works is that the AI is better at spotting missing coverage than at inventing realistic scenarios from scratch. It's a second pair of eyes, not a test generator. You still need to decide what behavior matters. The model just tells you where your own logic has holes.
This shifts the work from "ask for output" to "ask for critique," which forces you to understand your own tests. That understanding is the skill that transfers to debugging, to code review, to everything else.
Let the AI read your codebase, not just your file
The third practice is the least flashy and the most useful. Modern AI tools can index an entire repository and answer questions about it. That means you can ask "where do we handle session expiry?" and get a list of files and functions, instead of grepping and tracing calls by hand.
This sounds like a search tool, and it partly is. But it's better than search because it understands relationships. A student working on a Django project last week asked: "Which views call the format_price utility, and is any of them passing a string instead of a Decimal?" The tool returned three views, and in one of them, the value came straight from a form field, which is always a string. That's a bug that would have taken twenty minutes of manual tracing to find.
The habit here is to ask questions about the shape of the code, not about how to write new code. "What happens when this API is called without an auth token?" "Where are we mutating this shared list?" "Which parts of the system depend on this config value?" These are the questions that take real time to answer by reading, and the model can often answer them in seconds.
The tradeoff is trust. The model can be wrong about a codebase it was indexed on, especially if the code uses unusual patterns or if there are multiple files with similar names. We tell students to treat the answer as a lead, not a fact. When the tool says "this view is called from three places," verify it. But verification is faster than exploration, and that tradeoff is worth making.
There's also a privacy cost. Sending your repository to a third-party service means that code leaves your machine. For a student project, that's fine. For a production system with customer data, you need to check what your company allows. We do not know how the next wave of models will handle this, but for now, ask your employer or your professor before you paste anything sensitive.
The shape of the work changes
These three practices share a common theme. Each one reframes the AI as a partner that needs context and boundaries, not as an oracle. The prompt that describes the bug is context. The test review is a boundary on what you're willing to trust. The codebase question is a scoped search instead of a blank request.
What we see in practice is that students who adopt these habits get faster over time, not slower. The ones who paste whole files and ask for rewrites hit a wall when the code gets complex. The ones who write precise prompts and ask for critique end up with a mental model of their own code that's sharper, because they had to explain it clearly to get a good answer.
We do not know which model will be best next year, or whether these tools will keep their current shape. But the underlying skill—communicating what you want, checking what you get, and using the tool to fill a specific gap—will stay useful regardless of the underlying technology.
Common questions
How do I keep my code from being used to train a model?
Check the settings of the tool you're using. Most major assistants have a privacy mode that prevents your prompts from being used for training. For self-hosted options, you control the data entirely. If you're on a company project, ask your engineering manager what the policy is before you send anything. The honest answer is that you can't fully control what happens once data leaves your machine, so the safest approach is to avoid sending sensitive code altogether.
Will AI tools replace junior developers?
No, but they will change what junior developers do. The tasks that get automated are the mechanical ones: writing boilerplate, finding references, generating simple tests. What's left is the judgment—deciding what behavior matters, checking whether an answer is correct, and explaining tradeoffs to a team. Those are exactly the skills that junior developers are supposed to be learning. The danger is not that a junior gets replaced by a model; it's that a junior who relies on the model without understanding the output will never build those skills.
What's the best way to learn these tools without getting dependent on them?
Pick one small, real task—a bug you actually have, or a test you actually wrote—and use the AI to help with that specific thing. Then rewrite the solution by hand, from memory, without looking at the AI's output. If you can't, you learned the wrong lesson. Repeat this for a few weeks and you'll get the context-writing habit without losing the ability to code on your own.
Courses this relates to
Come and sit a class before you decide
Reading about it only gets you so far. Pick a day, sit in on a class that is already running, write some code, and talk to the students in it. Free, and nothing to pay afterwards unless you want to join.