Large language models (LLMs) are causing a stir in the dev community. This note documents a small background research and experiments I’ve done to investigate my burning question: “Can I (a roboticist) leverage an LLM to significantly reduce my development time?”

Goals

  • Dramatically reduce the amount of work required to migrate a ROS project to use Bazel.
    • Better understand the required work: What are the required steps? What makes it so laborious?
  • Understand the strengths and weaknesses of using LLM in a nontrivial project, e.g.,
    • Bazel migration project takes at least a few weeks of one entire eng. team. Can it be done by a single person in a few days?

Expected Impact

  • New flexibility in changing build system that traditionally require huge effort to migrate.

Background Research

Using Bazel as a Build System for ROS

Challenges

  • Bazelifying all external dependencies.
    • Cruise guys mention this in their talk and in ROS Discourse.
  • Something about Python dependencies.
    • Study mvukov’s comment (in mvukov/ruls_ros, I think) that describes the challenges of specifying Python dependencies in Bazel.

Existing Approaches

  1. Using ROS as system dependencies in Bazel.
  2. Updating ROS and all of its external dependencies to use Bazel.

See also: Background and Design Decisions section in mvukov/ruls_ros

Candidate ROS Projects to Migrate

Other Candidates Considered:

  • Nav2

LLM-Powered Code Generation

Initial Impressions on LLM Use Cases

  • The “consumption” side of LLM use cases (e.g., code comprehension, summarization) can increase developer velocity.
  • The “generation” side of LLM use cases (e.g., code completion, generation) is questionable; developers still need to check their code line-by-line.
  • “Test case generation” is interesting.
    • CodiumAI - Generating meaningful tests for busy devs
    • Creating test cases is more useful than generating untested code.
    • However, it’s not TDD; developers still need to provide an initial implementation (I think).

AI Agents

  • Significant-Gravitas/AutoGPT:
    • A pioneer AI agent.
    • I have heard that it has great documentation on what works and what doesn’t, but I haven’t been able to find it.
    • There are many alternatives and variants available.
  • smol-ai/developer:
    • An AI agent-like program synthesizer.
    • There are some alternatives and variants, such as GPT.
  • LLM Powered Autonomous Agents
    • A summary blog post on AI Agent research and demos.
  • TheR1D/shell-gpt:
    • It’s not an AI agent, but it seems to be highly customizable.

They are essentially for loop around LLM APIs. To me, the key challenge is making them more transparent and easier to interact with for developer users. One idea is transforming the for loop execution into the process developers are already familiar with, e.g., PR review process, TDD-like dev flow, commenting process, etc.

Next Steps

  1. Collect and analyze feedback for this idea.
    • Who cares about this?
      • Which (robotics) companies? Who are their customers?
    • Is the maintenance work a bigger or more laborious problem?
  2. Find a starting point; Couple ideas:
    1. Check out Autoware or MoveIt 2 and identify a leaf package to start converting to Bazel.
    2. Check out mvukov/rules_ros2 and identify a list of challenges that the author overcame.
  3. Assess pros and cons of AI agents:
    1. Try an AI agent to migrate a tiny ROS package to use Bazel.
    2. Search for AI agent TDD applications and try them out.
      • Can it migrate a tiny ROS package to use Bazel?
    3. Review how smol-ai/developer works.

Misc.

  • If the goal is to demonstrate the usefulness of LLM, I could focus on converting RVIZ plugins to foxglove extensions, which is another laborious task.