Coding with AI

From autocomplete to agents, and how to stay the engineer. About 1 h 30 min, intermediate level.

You'll be able to

• Match the right kind of AI coding tool to a task, from inline suggestions to agents.
• Review AI-written code line by line and check it with tests, including inputs designed to break it.
• Spot security, dependency and licensing risks in AI-generated code before you accept it.

From autocomplete to agents

AI coding tools sit on a spectrum of autonomy:

• Inline suggestions: GitHub Copilot proposes the next lines as you type.
• Chat about code: you paste or select code and ask for an explanation, a fix or a test.
• Editor agents: Cursor, or Copilot's agent mode, plan a change and edit several files at once.
• Terminal agents: Claude Code reads a project, runs commands and tests, and iterates while you approve its actions.
• App builders: Replit Agent sets up, builds and hosts a small app from a description.

The further along the spectrum, the more code appears per request, and the more you have to review. More autonomy doesn't mean less responsibility: you're still the engineer who ships it.

Before using any of them for coursework, read the course policy. Many programming courses restrict AI help or require disclosure, because writing the code yourself is how you learn it.

Give it context, and keep tasks small

Coding tools fail in the same way chat assistants do: they fill gaps with the most typical guess. Typical may not be what your project needs.

• Conventions: language version, libraries you already use, naming and formatting style.
• Constraints: “no new dependencies”, “must run on the lab machines”, “don't change the public interface”.
• Examples: point to an existing function that does something similar and say “follow this pattern”.

Many tools read a project instruction file, such as a CLAUDE.md or a rules file, so you don't repeat this every time.

Then keep each request small and testable. “Add a function that removes duplicate rows by email, with tests” is reviewable. “Build the whole data pipeline” produces hundreds of lines nobody reads carefully. For bigger jobs, ask for a plan first, correct it, then build it in steps.

Read every change

AI-written code looks tidy and confident, which makes errors easy to miss. Review it the way you'd review a new teammate's work:

• Read the diff, not just the final file, so you see everything that changed, including edits to code you didn't ask it to touch.
• Comment or ask about every line you don't understand. “Explain this line and what happens if the input is empty” is a good prompt.
• Check that functions and libraries exist. Models sometimes call methods that look plausible but aren't real, or use an old version of an API.
• Look at edge cases: empty input, missing values, unusual characters, very large files.
• Watch for shortcuts: an agent trying to make tests pass may weaken the test or special-case the example instead of fixing the logic.

If you can't explain what a piece of code does, you're not ready to accept it.

Tests are how you check

Reading catches a lot, but running code against known answers catches more. Tests turn “looks right” into “does what I specified”.

• Write down the expected behavior first, in plain words: given this input, the output should be that.
• Ask the AI for tests, then review them. Tests written by the same model can share its misunderstanding, so check that each one tests what you actually want.
• Include hostile inputs: an empty file, a missing column, a duplicated header, a date in a different format, text where a number should be.
• Run the tests yourself and see them fail when you break the code on purpose. A test that never fails checks nothing.

Keep the tests once they work. They let you ask for future changes with confidence, because you'll know immediately if something that used to work breaks.

Security, dependencies and licensing

Some risks aren't visible when the code runs fine:

• Secrets: never paste passwords or API keys into prompts or hard-code them; use environment variables or a secrets store.
• Unsafe input handling: check for queries built by pasting user input into strings (SQL injection), and for input that's never validated.
• Dependencies: models sometimes suggest packages that don't exist, and an attacker could publish malware under such a name. Confirm a package is real, maintained and the one you meant before installing it.
• Agent permissions: agents that run commands can delete files or send data. Approve actions you understand and work in a copy or a version-controlled project.
• Prompt injection: an agent that reads web pages or files can be steered by instructions hidden in them.
• Licensing: suggestions can resemble existing public code. Check dependency licenses, and use settings that block suggestions matching public code where a tool offers them.

Build, then review: a CSV-cleaning script

Request: “Write a Python script that cleans contacts.csv: trim spaces, drop rows without an email, remove duplicate emails, and write clean.csv. Use only the standard library. Add tests.”

Review, line by line:

• It drops rows with any blank field, not just a blank email. Rows with a missing phone number vanish. You ask it to check only the email column.
• Duplicates are compared case-sensitively, so “A@usc.edu” and “a@usc.edu” both survive. You ask it to compare lowercase emails.
• One line uses a function you don't recognize. You ask for an explanation; it's fine, and you add a comment.

Tests: the generated tests only use tidy input. You add three: an empty file, a file with no email column, and an email with trailing spaces. The empty-file test crashes the script. You ask for a clear error message instead.

Result: a script you can explain, with tests that fail when you break it on purpose.

Try it

A small CSV-cleaning script with your comments on every line you didn't understand at first, a set of tests including deliberately broken inputs, and a note on what the review caught.