Packages
fnord
0.4.40
0.9.40
0.9.39
0.9.38
0.9.37
0.9.36
0.9.35
0.9.34
0.9.33
0.9.32
0.9.31
0.9.30
0.9.29
0.9.28
0.9.27
0.9.26
0.9.25
0.9.24
0.9.23
0.9.22
0.9.21
0.9.20
0.9.19
0.9.18
0.9.17
0.9.16
0.9.15
0.9.14
0.9.13
0.9.12
0.9.11
0.9.10
0.9.9
0.9.8
0.9.7
0.9.6
0.9.5
0.9.4
0.9.3
0.9.2
0.9.1
0.9.0
0.8.99
0.8.98
0.8.97
0.8.96
0.8.95
0.8.94
0.8.93
0.8.92
0.8.91
0.8.90
0.8.89
0.8.88
0.8.87
0.8.86
0.8.85
0.8.84
0.8.83
0.8.82
0.8.81
0.8.80
0.8.79
0.8.78
0.8.77
0.8.76
0.8.75
0.8.74
0.8.73
0.8.72
0.8.71
0.8.70
0.8.69
0.8.68
0.8.67
0.8.66
0.8.65
0.8.64
0.8.63
0.8.62
0.8.61
0.8.60
0.8.59
0.8.58
0.8.57
0.8.56
0.8.55
0.8.54
0.8.53
0.8.52
0.8.51
0.8.50
0.8.49
0.8.48
0.8.47
0.8.46
0.8.45
0.8.44
0.8.43
0.8.42
0.8.41
0.8.40
0.8.39
0.8.38
0.8.37
0.8.36
0.8.35
0.8.34
0.8.33
0.8.32
0.8.31
0.8.30
0.8.29
0.8.27
0.8.26
0.8.25
0.8.24
0.8.23
0.8.22
0.8.21
0.8.20
0.8.19
0.8.18
0.8.17
0.8.16
0.8.15
0.8.14
0.8.13
0.8.12
0.8.11
0.8.1
0.8.0
0.7.24
0.7.23
0.7.22
0.7.21
0.7.20
0.7.19
0.7.18
0.7.17
0.7.16
0.7.15
0.7.14
0.7.13
0.7.12
0.7.11
0.7.10
0.7.9
0.7.8
0.7.7
0.7.6
0.7.5
0.7.3
0.7.2
0.7.1
0.7.0
0.6.9
0.6.8
0.6.7
0.6.6
0.6.5
0.6.4
0.6.3
0.6.1
0.6.0
0.5.9
0.5.8
0.5.7
0.5.6
0.5.5
0.5.4
0.5.3
0.5.2
0.5.1
0.5.0
0.4.44
0.4.43
0.4.42
0.4.41
0.4.40
0.4.39
0.4.38
0.4.37
0.4.36
0.4.35
0.4.34
0.4.33
0.4.32
0.4.30
0.4.29
0.4.28
0.4.27
0.4.26
0.4.25
0.4.24
0.4.23
0.4.22
0.4.21
0.4.20
0.4.19
0.4.18
0.4.17
0.4.16
0.4.15
0.4.14
0.4.13
0.4.12
0.4.11
0.4.10
0.4.9
0.4.8
0.4.7
0.4.6
0.4.5
0.4.4
0.4.3
0.4.2
0.4.1
0.4.0
0.3.0
0.2.0
0.1.0
AI code archaeology
Current section
Files
Jump to
Current section
Files
lib/ai/agent/reviewer.ex
defmodule AI.Agent.Reviewer do
@model "gpt-4o"
@max_tokens 128_000
@prompt """
You are the Code Review Agent, responsible for reviewing code submissions.
You will be presented with information about a topic branch, including the list of commits and the git diff from the base branch.
Remember that newly added files will not be available in your database, so they cannot be investigated with the file_info_tool or spelunker_tool!
Initially, your conversation will occur with the Planner Agent, who will suggest strategies for researching the code to be reviewed.
Once the Planner Agent indicates that you have sufficient context, proceed with your review for the user.
# Step 1
Use your tools to learn how the current code functions.
Investigate related files and modules that may be affected by the changes (for example, if an existing function is altered, search for other call sites to see how it is used).
Read the individual commits using the git_show_tool to understand the changes made. You can sometimes glean the purpose of the changes from the commit messages and the sequence of the change diffs.
Take the time necessary to understand the features and behaviors being modified.
Try to identify the _purpose_ of the changes using the provided diff, commits, and the results of your research.
# Step 2
Summarize the current behavior and workflow that is the subject of the change.
Assume that the user is NOT familiar with the this area of the codebase.
Walk through the current workflow step by step and ensure that the user has a **thorough** understanding of how the existing code works.
Be sure to cite files, symbols, and quote relevant code for the user's benefit.
# Step 3
Walk the user through the changes that are being proposed.
Explain the nature and purpose of each change thoroughly.
When two hunks are interdependent, explain the relationship between them.
Clearly identify when code was moved from one location to another.
Clearly identify when code was added or removed.
Be sure to cite files, symbols, and quote relevant code for the user's benefit.
Present your explanation in a manner that gently guides the user through the changes.
# Step 4
Provide feedback on the quality of the changes.
Identify any concrete, logical bugs.
Identify mispellings, typos, and grammatical errors in new comments or documentation.
Identify any areas where the code is confusing or unnecessarily complex and provide a concrete example of how it could be improved.
Where appropriate, try to find existing code that may already handle the existing change or that could simplify it significantly.
Evaluate whether the existing test suite or newly added test cases cover the changes sufficiently. If not, suggest additional test cases as well as where those cases should be added (e.g. an existing test file or a new one).
Ensure that ALL of your feedback is concrete (citing specific locations in the code) and actionable. Do not provide vague feedback, such as "ensure all documentation is correct."
# Tone
Do not use flowery prose. Keep your tone conversational and brief.
Be polite but merciless in your feedback. The user is looking for a thorough review, not a pat on the back.
Apply markdown styling to your comments to highlight important phrases and significant information to assist the user in visually parsing your response.
# Template
Use the following template when responding to the user:
# Synopsis
[your summary of the changes here]
# Current Behavior
[your walkthrough of the current behavior here]
# Proposed Changes
[your walkthrough of the changes here]
# Feedback
[your itemized feedback here]
"""
@tools [
AI.Tools.Search.spec(),
AI.Tools.ListFiles.spec(),
AI.Tools.FileInfo.spec(),
AI.Tools.Spelunker.spec(),
AI.Tools.GitShow.spec(),
AI.Tools.GitPickaxe.spec(),
AI.Tools.GitDiffBranch.spec()
]
# -----------------------------------------------------------------------------
# Behaviour implementation
# -----------------------------------------------------------------------------
@behaviour AI.Agent
@impl AI.Agent
def get_response(ai, opts) do
with {:ok, _} <- Git.git_root(),
{:ok, response, {label, usage}} <- build_response(ai, opts) do
UI.report_step(label, usage)
UI.flush()
IO.puts(response)
{:ok, response}
else
{:error, :not_a_git_repo} ->
UI.error("Not a git repository", opts.project)
{:error, :not_a_git_repo}
{:error, reason} ->
UI.error("Error", reason)
{:error, reason}
end
end
# -----------------------------------------------------------------------------
# Private functions
# -----------------------------------------------------------------------------
defp build_response(ai, opts) do
with {:ok, topic} <- Map.fetch(opts, :topic),
{:ok, base} <- Map.fetch(opts, :base),
{:ok, prompt} <- user_prompt(topic, base) do
UI.report_step("Reviewing", topic)
AI.Response.get(ai,
on_event: &on_event/2,
max_tokens: @max_tokens,
model: @model,
tools: @tools,
system: @prompt,
user: prompt,
use_planner: true
)
end
end
defp user_prompt(topic_branch, base_branch) do
with {:ok, {commits, changes}} <- Git.diff_branch(topic_branch, base_branch) do
{:ok,
"""
# Reviewing #{topic_branch} against #{base_branch}
## Commits
#{commits}
## Changes
#{changes}
"""}
end
end
defp on_event(:tool_call, {"search_tool", %{"query" => query}}) do
UI.report_step("Searching", query)
end
defp on_event(:tool_call, {"list_files_tool", _args}) do
UI.report_step("Listing files in project")
end
defp on_event(:tool_call, {"file_info_tool", %{"file" => file, "question" => question}}) do
UI.report_step("Considering #{file}", question)
end
defp on_event(
:tool_call,
{"spelunker_tool",
%{
"question" => question,
"start_file" => start_file,
"symbol" => symbol
}}
) do
UI.report_step("Spelunking", "#{start_file} | #{symbol}: #{question}")
end
defp on_event(:tool_call, {"git_show_tool", %{"sha" => sha}}) do
UI.report_step("Inspecting commit", sha)
end
defp on_event(:tool_call, {"git_pickaxe_tool", %{"regex" => regex}}) do
UI.report_step("Archaeologizing", regex)
end
defp on_event(:tool_call, {"git_diff_branch_tool", %{"topic" => topic, "base" => base}}) do
UI.report_step("[file_info] Diffing branches", "#{base}..#{topic}")
end
defp on_event(_, _), do: :ok
end