An AI suggestion is a draft, never a merge-ready commit

Free preview 3 min to read

Two things that look the same on screen

An agentic tool, the kind AI tools: introduction (Cursor & Antigravity) covered, hands back a method for Article that looks finished: tidy indentation, a sensible name, no red underline. A pull request from a teammate who wrote and tested the same method by hand looks the same on screen. Syntax highlighting doesn't tell "someone checked this" from "a model predicted this looks right." That sameness is why this lesson exists.

What "draft" means here

A draft is something written to be checked, not something already checked. An agentic tool's output is a draft in that sense. It was produced by predicting a plausible continuation of your request from patterns in its training, not by reasoning through this project's rules and confirming them. That doesn't make it worthless; a useful first pass is worth having. It makes it as unfinished as a first pass a junior teammate hands you before testing it.

What "merge-ready" requires

In this project, merge-ready code meets four conditions:

  1. It follows Rails conventions.
  2. It lands in a named bounded context. The project's conventions file, MEMORY.md, calls the domain-driven layout strict: no controllers, models, services or helpers at the root level.
  3. It doesn't quietly break a rule elsewhere in the codebase.
  4. A person who understands why it's correct has checked it. Watching it run isn't enough.

An agentic tool's draft can't meet the fourth condition on its own. Running without an error isn't the same as being correct. Article.new(params[:article]) doesn't show that gap; it shows the opposite. Lesson 1 of Controller params & security showed Rails refusing it with ActiveModel::ForbiddenAttributesError, a safeguard failing loudly. The dangerous draft runs clean: params.require(:article).permit(:title, :published_at, :admin_only), a permit list one field too long. Nothing raises, nothing warns, and a request can now set a column no form was meant to reach.

Where this course is going

Lesson 2 asks the question this one sets up: once a draft ships and turns out wrong, whose name is on the mistake? Lesson 4 comes back to article_params, the method Controller params & security spent a whole course opening, as the case study for a draft that looks finished and isn't.

Key takeaways

  • An agentic tool's output and a tested human change can look identical; syntax highlighting never shows which one was checked.
  • "Draft" means produced by predicting a plausible continuation, not by confirming this project's rules.
  • Running without an error isn't being correct; the draft to worry about runs clean, like a permit list with one field too many.
  • A draft becomes merge-ready only after a person who understands why it's correct has checked it.
Lesson 1 of 7 · free

Keep going with lesson 2

Who owns the result: accountability doesn't transfer

Shows that responsibility for a shipped change stays with the person who reviewed and approved it.

A free account also gives you the quizzes, your progress and notes, and the discussion.

Type to start searching...