Java SE 21 — 1Z0-830

Appearance

Lesson 01 · Generating Code & Tests with AI ​

Beyond the 1Z0-830 exam

AI coding assistants (LLMs) are now part of the normal workflow. Used well, they accelerate scaffolding, boilerplate, refactoring, and test generation. Used badly, they introduce subtle bugs at speed. This lesson is about the workflow that captures the upside.

Objectives

After this lesson you will be able to:

  • Frame the assistant as a fast, fallible drafter, not an authority.
  • Use AI effectively for scaffolding, boilerplate, refactoring, and tests.
  • Keep changes small and reviewable.
  • See why the rest of this course is what makes AI assistance safe.

The right mental model ​

Treat the assistant as a capable but fallible junior developer who types very fast: great at producing a first draft, prone to confident mistakes, and in need of review. The value isn't the generation — it's your review and verification turning a draft into shippable code. You can only do that for code you understand, which is why Modules 00–16 matter here.

Where AI shines ​

TaskWhy it fits
Scaffoldinga new class, a test skeleton, a builder — mechanical, low-risk
Boilerplateequals/hashCode, DTOs, mappers, parameterized-test data
Refactoringrename, extract method, convert a loop to a stream — you verify behavior is unchanged
Explaining codesummarizing an unfamiliar method before you change it
Test generationenumerating cases you might forget — then you check the oracle

Where it's risky ​

  • Novel logic with subtle correctness requirements (the lab's overflow/integer-division bugs).
  • Security-sensitive code (auth, crypto, input handling) — Module 19.
  • Concurrency — race conditions that pass tests by luck (Module 07).
  • Anything against an unfamiliar API — hallucinated methods (next lesson).

A workflow that works ​

  1. Specify intent — signature, constraints, and edge cases (Lesson 03), not just a name.
  2. Generate a small, focused change — one method or class, not a feature.
  3. Read it line by line — does each line do what it claims? (Lesson 02)
  4. Write or verify the test oracle yourself — don't accept AI's tests as truth (Lesson 03).
  5. Run it — compile, test, and exercise edge cases (Lesson 04).
  6. Keep diffs reviewable — small changes are reviewable; 800-line generations are not.

Generate tests, but own the oracle

Asking AI to "write tests for this method" is a great way to enumerate cases you'd miss — empty inputs, boundaries, nulls. But the AI may assert the wrong expected value (especially if it wrote the buggy code too). You supply the oracle: what the correct answer actually is. The lab's tests were written to expose the bugs, not to bless them.

Gotcha — fluency is not correctness

LLM output is optimized to be plausible, and plausible code reads as confident and idiomatic even when it's wrong. A clean-looking method with a tidy comment can still divide by zero on empty input. Never let polish substitute for verification.

Key Takeaways ​

  • Treat the assistant as a fast, fallible junior — the value is in your review and verification.
  • AI shines at scaffolding, boilerplate, refactoring, explanation, and enumerating test cases.
  • It's risky for novel logic, security, concurrency, and unfamiliar APIs.
  • Work in small, reviewable changes; read every line; own the test oracle.
  • Plausible ≠ correct — the whole course is the judgment that makes AI assistance safe.

Lesson Quiz ​

Lesson Quiz · Generating Code & Tests with AI0 / 5

  1. The most useful mental model for an AI coding assistant is…

    • AAn infallible expert
    • BA fast but fallible junior whose drafts you review and verify
    • CA search engine
    • DA compiler

  2. Which task is LOWEST risk to delegate to AI?

    • ANovel concurrency logic
    • BBoilerplate like a DTO or equals/hashCode you then verify
    • CCryptographic code
    • DSecurity input handling

  3. When you ask AI to 'write tests for this method', what must you still do?

    • ANothing — accept them
    • BSupply/verify the oracle — the AI may assert wrong expected values, especially if it wrote the code
    • CDelete the method
    • DRun them only once

  4. Why keep AI-generated changes small?

    • ATo save tokens
    • BSmall diffs are reviewable; large generations hide subtle bugs
    • CLarge changes don't compile
    • DIt's a Git limitation

  5. Why is 'it looks clean and idiomatic' insufficient?

    • AClean code is always correct
    • BLLM output is optimized to be plausible; polish doesn't guarantee correctness
    • CIdiomatic code can't have bugs
    • DComments prove correctness

Next: Critically Reviewing AI Output. This module's lab is in labs/src/main/java/com/jse21/m21_ai/.