[Examples] Add autonomous code optimization example#9182
[Examples] Add autonomous code optimization example#9182alex000kim wants to merge 5 commits intoskypilot-org:masterfrom
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a powerful new example that enables autonomous code optimization for open-source projects. By integrating coding agents with SkyPilot, the system can intelligently identify performance bottlenecks, search academic literature for optimization strategies, and execute parallel experiments across cloud virtual machines to iteratively improve code efficiency. This significantly streamlines the process of performance tuning and research for developers. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a new "Autonomous Code Optimization" example for SkyPilot, encompassing documentation, a detailed README, a SkyPilot experiment configuration, agent instructions, and a setup script. Feedback from the review suggests several improvements: renaming pi-autoresearch to autonomous-code-optimization for clarity in the documentation, correcting MyST directive syntax in the new documentation page, mitigating a potential command injection vulnerability in the experiment.yaml due to eval usage, and improving the efficiency of work directory preparation in the agent instructions to avoid copying unnecessary files.
| :::{admonition} experiment.yaml | ||
| :class: dropdown | ||
|
|
||
| :::{literalinclude} ../../../../examples/autonomous-code-optimization/experiment.yaml | ||
| :language: yaml | ||
| ::: | ||
| ::: |
There was a problem hiding this comment.
The MyST directive syntax appears to be incorrect. Directives should be opened and closed with three colons (:::), but four colons (::::) are used here and in other places in the file. This will likely break documentation rendering.
This block should be:
:::{admonition} experiment.yaml
:class: dropdown
:::{literalinclude} ../../../../examples/autonomous-code-optimization/experiment.yaml
:language: yaml
:::
:::Please correct all similar occurrences in this file.
| bash setup_deps.sh | ||
| else | ||
| echo ">>> No setup_deps.sh found, running BUILD_CMD: ${BUILD_CMD}" | ||
| eval "${BUILD_CMD}" |
There was a problem hiding this comment.
Using eval with a user-configurable environment variable like BUILD_CMD can introduce a command injection vulnerability. While users of SkyPilot generally control their own execution environments, it's a security best practice to avoid eval when possible. A similar issue exists on line 57. Consider alternatives that don't involve evaluating a raw command string, such as using a dedicated build script and passing safe parameters to it.
| mkdir -p /tmp/autoresearch/exp-03 | ||
| cp -r . /tmp/autoresearch/exp-03/ |
There was a problem hiding this comment.
The instruction to use cp -r . /tmp/autoresearch/exp-03/ to create an isolated workdir can be inefficient and risky. It will copy all files from the current directory, including build artifacts, version control directories (.git), and potentially very large files not needed for the experiment. This can slow down experiment setup and lead to unexpected behavior.
Consider suggesting a more robust method, such as:
- Using
rsyncwith an exclude list to avoid copying unnecessary files. - Using
git archiveto create a clean export of the repository files.
For example:
# Using rsync
rsync -av --exclude='.git' --exclude='build/' . /tmp/autoresearch/exp-03/This would provide a cleaner and more efficient way to prepare the experiment directory.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
- Rename pi-autoresearch.md to autonomous-code-optimization.md to match toctree ref - Fix nested MyST directive syntax with proper colon counts - Replace eval with bash -c for BUILD_CMD execution - Use rsync with excludes instead of cp -r for experiment workdir setup
Add a new example for autonomous code optimization using SkyPilot, where a coding agent (Claude Code, Codex, etc.) uses SkyPilot VMs to parallelize performance experiments on any open-source project