What Is an AI Coding Assistant?

AI coding tools can produce code that looks finished before you have had time to understand the problem.

That is why the first question is not “which model is best?”

The first question is:

What entered the system, what produced the candidate output, and what still has to be verified by the developer?

Start with the durable architecture

A modern coding assistant may combine several parts:

YOUR REQUEST
     +
SELECTED CONTEXT
     +
MODEL
     +
OPTIONAL RETRIEVAL / TOOLS
     ↓
CANDIDATE OUTPUT OR ACTION PLAN

The exact implementation varies by product. Some interfaces work mostly from text you provide. Others can inspect open files, search a repository, retrieve documentation, call tools, or propose edits.

The durable idea is that the system uses the information available to it to generate a candidate response. That candidate can be useful, incomplete, misleading, insecure, outside scope, or simply wrong.

It is not evidence merely because it is fluent.

Why generated code can look more trustworthy than it is

Python has strong patterns. A generated function can have:

• correct indentation;
• believable names;
• reasonable type hints;
• a professional docstring;
• plausible tests; and
• a confident explanation.

None of those prove that the function satisfies your requirement.

Consider a requirement:

A battery level of 20 or lower is LOW.

Candidate code:

def is_low_battery(level):
    return level < 20

The function is clean Python. The boundary is still wrong.

A learner who checks only syntax can approve a logic defect.

A learner who checks the contract asks:

assert is_low_battery(20) is True

That test exposes the mismatch.

“Hallucination” is only one failure mode

You will hear the word hallucination used for generated claims or details that are unsupported or false.

That matters, but code review needs a broader failure model.

A candidate can fail because it:

solves the wrong requirement
uses an API incorrectly
assumes a package/version you do not have
changes files outside the task
weakens an existing test
adds an unnecessary dependency
handles only the happy path
hides an error instead of fixing the cause
creates code nobody on the team can explain

Notice that several of those failures could occur even if every library and function name is real.

Context limits what the assistant can know

Suppose you ask:

Fix my save bug.

But the system cannot see:

• your current storage.py;
• the traceback;
• the JSON fixture;
• the tests;
• the required file format; or
• the change you made five minutes ago.

The assistant has to fill gaps with assumptions.

A better development request supplies relevant context without exposing restricted data:

Requirement: save a list of player dictionaries to JSON.
Observed failure: TypeError on this line...
Relevant function: ...
Expected file shape: ...
Constraint: standard library only.

Better context reduces ambiguity. It does not remove the need to verify the answer.

There are different levels of tool access

A coding interface may have different capabilities.

Suggestion-only

It returns text or code for you to copy or apply.

Risk is limited because the output has no direct project effect until a human acts.

Editor-aware

It can inspect selected project context or propose patches.

Now you must inspect exactly which files and lines changed.

Tool-using / agentic

It may be able to search, edit, run commands, execute tests, or repeat actions based on results.

The model is not automatically more correct because tools are connected. The tools increase consequence.

Unit 17 handles that governance directly.

Generated tests need review too

A particularly dangerous loop is:

AI misunderstands requirement
        ↓
generates implementation for wrong requirement
        ↓
generates test for same wrong requirement
        ↓
all generated tests pass

Green output is real evidence that those tests passed. It is not proof that the requirement was interpreted correctly.

The requirement must remain outside that self-confirming loop.

Responsibility stays with the project owner

For this course, the rule is simple:

If you accept code into your project, you are responsible for understanding and verifying the accepted behavior.

That does not mean you personally typed every character.

Developers already depend on compilers, libraries, code generators, documentation, teammates, and frameworks. Ownership means you can explain why the code is there, what contract it serves, how you checked it, and what limitations remain.

Privacy and repository boundaries

Do not paste or expose:

• passwords;
• API keys or access tokens;
• private student information;
• unpublished school data;
• private repository content that you are not authorized to share;
• credentials hidden in .env files; or
• copyrighted/private material merely because a tool accepts large context.

A convenient input box is not permission to disclose data.

Controlled comparison

Take this requirement:

Create a function count_active(robots) that returns how many dictionaries
have active == True. Missing active keys should count as False.
Do not mutate the input list.

Before asking any AI system, write the tests you think matter:

def test_count_active_mixed():
    robots = [
        {"name": "r1", "active": True},
        {"name": "r2", "active": False},
        {"name": "r3"},
    ]
    assert count_active(robots) == 1


def test_count_active_does_not_mutate_input():
    robots = [{"name": "r1", "active": True}]
    before = [item.copy() for item in robots]
    count_active(robots)
    assert robots == before

Now compare any candidate implementation with those explicit claims.

If no approved AI tool is available, use a supplied candidate implementation. The review skill is exactly the same.

What to carry forward

AI-assisted development is not a separate universe from the Python work you already did.

It depends on the same developer skills:

requirements
files
Git diffs
Python behavior
tracebacks
tests
dependencies
architecture

The assistant can accelerate candidate generation. It does not remove those layers.

Lesson 2 turns that into a repeatable review loop. Lesson 3 examines where AI can help with explanation, debugging, and test design without quietly becoming the source of truth.