Courses tend to end with encouragement. Here is a list of things that do not work well
instead, because knowing the edges is more useful than being told you can do anything.

1. Large changes across many files

Renaming one thing everywhere is fine. Restructuring how a system works is not. The change
becomes too big to review, and unreviewed change is where the expensive mistakes live.

Break it into pieces you are willing to read. If you cannot, that is a signal about the
change, not about the tool.

2. Anything that depends on knowledge not in the repository

Why the discount is 12% and not 15%. Which customer must never be emailed automatically.
Which table looks unused but is read by a report once a quarter.

None of that is in the code. The agent will make a sensible-looking decision and be wrong in
a way that takes weeks to surface.

3. Performance work

“Make it faster” without measurement produces changes that look faster. Measure first, give
the agent the measurement, then change one thing and measure again.

4. Anything where being subtly wrong is expensive

Money. Dates and time zones. Permissions. Anything medical or legal.

You saw the pattern in Module 4 twice. The code runs, looks right, and is wrong. Where that
is costly, slow down, write the cases yourself, and check by hand.

5. Genuinely new problems

These tools are strongest where there are many examples of similar work. On a problem that
is actually novel, you will get a confident answer shaped like the nearest familiar thing,
which is often the wrong shape entirely.

6. Security-sensitive code

Authentication, permissions, anything handling money or personal data. Agents write
plausible security code. Plausible is not a standard anybody accepts here. Get it reviewed
by a person who knows the area.

7. A codebase that is already bad

It copies what it sees. In a mess, it adds tidy-looking mess. The tool does not raise the
standard of a project; it matches it.

8. Team decisions

An agent will implement whatever you tell it, including a decision your team has not agreed
and will reverse next week. It has no opinion about whether the work should be done.

This is Lesson 1.7’s point arriving with real consequences. Deciding what to build is still
yours, and it is now the larger part of the job.

What this list is not

It is not a reason to avoid these tools. Everything in this course still stands.

It is a map of where to slow down. People who get burned are not the ones who used AI. They
are the ones who used it at the same speed everywhere.

Try this before the final project

  1. Which of these eight have you already hit? Be honest.
  2. Which is most likely in your own work?
  3. Pick one and write down what you will do differently.