Blog

Criticize AI: A code review before you plan the next change

Most AI tools jump from prompt to diff. On real repos, you need a structured review of what you already built — saved in the project — before you commit to a plan.

BrownfieldExisting projectsCode review

Most AI coding tools jump straight from prompt to diff. That works for greenfield ideas. It breaks down on real repos — the ones with history, shortcuts, half-finished refactors, and assumptions nobody remembers.

You do not need another agent that ships code blindly. You need something that reads what you already built and tells you what is worth fixing before you commit to a plan.

That is Criticize AI.

What it actually does

Point AutonomLayer at an existing project folder. Describe what you want to change. Hit Criticize.

The agent opens your IDE, explores the codebase, and produces a structured review — saved as criticism{id}.md in your repo root. No refactors. No surprise PRs. Review only.

You get findings you can read, edit, and approve. Then — and only then — you generate an update plan from what the review actually found.

Built for brownfield, not toy demos

Criticize is designed for developed repos: production apps, internal tools, side projects you have touched for months.

The agent is instructed to:

  • Explore the existing codebase — real files, real structure
  • Surface issues with severity and location — not vague “consider improving X”
  • Propose an update plan scoped to changes, not greenfield scaffolding
  • Stop before implementing — criticism is a separate step from execution

That separation matters. Review and build are different modes. Mixing them is how you get confident rewrites that break things you forgot existed.

Pick your lens — or review everything

Not every update needs the same scrutiny. Before you run Criticize, choose one or more focus areas:

AreaWhat it looks at
SecurityAuth, secrets, injection, dependencies
UX & interaction logicFlows, states, empty and error paths
AccessibilityKeyboard, contrast, labels, focus
PerformanceSlow paths, bundle size, wasted work
Architecture & structureCoupling, duplication, layering
Error handling & reliabilityGuards, retries, crash risks
Testing & qualityCoverage gaps, flaky tests
API & data contractsSchemas, validation, breaking changes
Privacy & compliancePII, logging leaks, retention
Documentation & maintainabilityStale docs, onboarding friction

Leave them all unchecked and you get a general review across practical dimensions. Tighten the scope when you already know the risk — security before a launch, architecture before a big refactor.

Add optional notes: “we are adding billing,” “mobile web is the priority,” “do not touch the auth module.” The review stays anchored to your intent.

What lands in your repo

Each run creates a markdown report with a consistent shape:

  1. Summary — the biggest issues and opportunities in plain language
  2. Findings — per item: area, severity (low / medium / high), location, issue, and recommendation (no code yet)
  3. Suggested update plan — a numbered list of changes AutonomLayer should plan next

The file lives in your project. It shows up in your project update history alongside repo summaries — so “what did we review last Tuesday?” has an answer.

You stay in control

Criticize does not lock you in. When the report comes back, you can edit the findings in the app — trim noise, add context, reject false positives. Then tap Update plan to turn the approved criticism into executable steps.

Run it again anytime. Changed the codebase since last review? Criticize once more before the next plan.

Optional paths after criticism:

  • Auto upgrade — generate an update plan automatically when criticism finishes
  • Auto pipeline (Premium) — criticism → repo summary → plan → start steps, hands-off

Why this beats “just ask the AI to fix it”

A generic “improve my app” prompt optimizes for motion — files changed, lines added. Criticize optimizes for judgment:

  • Ground truth — the agent reads your repo, not an imagined version
  • Structured output — severity, location, recommendation; not a wall of chat
  • Artifact in the repo — the review persists; it is not lost in a thread
  • Clean handoff to planning — findings become the brief for the next mission

It is the difference between “the AI said it looked fine” and “here is what we agreed to fix, in writing, in the project.”

When to use it

  • Before a brownfield update — know the landmines before you plan
  • After a fast sprint — catch security, UX, or test gaps you shipped under pressure
  • Before a refactor — architecture and coupling review without committing to a rewrite
  • When onboarding to an unfamiliar repo — a structured first pass in minutes

If the code already exists and the stakes are real, Criticize belongs upstream of planning — not as an afterthought.

The flow, end to end

  1. 1

    Open an existing project

    Launch AutonomLayer and point it at your repo folder.

  2. 2

    Describe your update idea

    Brief or detailed — what you want to change next.

  3. 3

    Tap Criticize

    Pick focus areas and optional notes for the AutonomLayer team.

  4. 4

    Review the report

    The IDE writes criticism{id}.md. Edit findings in the app if needed.

  5. 5

    Update plan

    Turn approved criticism into executable steps.

  6. 6

    Optional: Auto pipeline

    Premium users can chain summary, plan, and launch automatically.

Available in the existing project flow on AutonomLayer for macOS. Open a folder. Describe the change. Criticize first. Plan second. Build with confidence.