Otto/Docs
← Otto

PR Feedback Loop

Otto doesn't just create PRs — it responds to code review feedback and makes changes.

How It Works

When someone leaves a review comment on an Otto-created PR:

  1. Otto reads the feedback — Understands the question or request
  2. Makes changes — Modifies the code or adds clarifying comments
  3. Pushes a new commit — Updates the PR with the fixes
  4. Responds inline — Explains what was changed and why

Real Example

Here's Otto responding to a code review question on its own PR:

In this example:

  • Reviewer asked: "Does execution need to continue or do we need an early return here?"
  • Otto explained: Why execution must continue (to set flags and store IDs)
  • Otto clarified: Added a code comment in a follow-up commit to prevent future confusion

The entire interaction happened inline on the PR, just like a human engineer would respond to feedback.

What Otto Handles Well

Questions About Logic

Otto can explain why it implemented something a certain way, referencing line numbers and walking through the control flow.

Code Improvements

  • Adding null checks or validation
  • Refactoring nested logic into early returns
  • Extracting helper functions
  • Fixing off-by-one errors

Style and Conventions

  • Using const vs let
  • Adding type annotations
  • Following naming patterns
  • Applying consistent formatting

Bug Fixes

  • Handling edge cases (null/undefined)
  • Correcting error codes (404 vs 500)
  • Fixing race conditions

Best Practices

Be specific: "Add email validation using class-validator" beats "add validation"

One topic per comment: Break complex feedback into separate review comments

Use GitHub suggestions: Otto applies inline code suggestions directly

Ask questions: Otto can explain its implementation choices — don't hesitate to ask "why?"

When to Use a New Ticket Instead

For major changes like:

  • Architectural refactoring across multiple files
  • Changing core design decisions
  • Adding entirely new features

Consider creating a new ticket with updated requirements instead of requesting major rework in code review. Otto's lifecycle flow (clarify → plan → implement) handles substantial changes better than PR feedback.