New Claude Code toolkit helps student programmers turn intended robot behavior into WPILib 2027-compatible Java code, tests, simulations, and pre-deployment evidence. And it’s free.
FOR IMMEDIATE RELEASE
BOSTON, Massachusetts — October 6, 2026 — [un]labs today announced the release of the Unlabs AI Toolkit for FRC 2027 Season Teams, version 1.0.0_Alpha-7, an AI-assisted development toolkit designed for student programmers participating in the FIRST Robotics Competition.
The toolkit is available now at:
https://unlabs.co/projects/unlabs-ai-toolkit-frc-2027/
The toolkit runs within Claude Code and works with an FRC team’s WPILib project. It helps students describe how a robot mechanism should behave, define its limits and success conditions, and then create WPILib 2027-compatible Java code that supports the agreed behavior.
Students can also use the toolkit to create laptop-based tests, work with the WPILib desktop simulator, investigate defects, review robot code, and run a structured pre-deployment validation.
The toolkit uses a behavior-first workflow. Before code is written, the student and the assistant state:
The student reviews and approves these requirements. The code follows the agreed behavior.
This process gives less-experienced programmers a practical place to start. A student does not need to know every WPILib class or begin with a blank Java file. The student must still make the engineering decisions, review the work, and verify its behavior.
“A student programmer should be able to begin with a clear statement of what the robot must do, not with a blank file and a list of unfamiliar class names,” said Chris Kelley, Co-Founder and Managing Member of [un]labs. “The toolkit keeps the student responsible for that decision. It then gives the student a structured way to create the code, test the stated behavior, use simulation, and examine the evidence before that code reaches a robot.”
Access to a competition robot is limited during an FRC build season. The robot may be incomplete, under mechanical repair, or in use by another group. Or, as is the case for the 2027 season, the controller hardware may not even be available yet.
Students use the toolkit and the WPILib desktop simulator to observe supported robot behavior without deploying code to physical hardware. This lets a team find some software defects before hardware testing begins, and they can begin this process today.
The alpha release includes workflows that help students:
The toolkit reads the team conventions stored in the project’s CLAUDE.md file. This helps new work follow the team’s selected motor controllers, naming rules, and subsystem structure.
The project publishes:
The Unlabs AI Toolkit for FRC 2027 Season Teams is available now:
https://github.com/unlabs-llc/unlabs-ai-toolkit-frc-2027/
Teams should begin with the web version of the Student Guide:
https://unlabs.co/projects/unlabs-ai-toolkit-frc-2027/student-guide/
Teams can then install the toolkit and use the WPILib desktop simulator to develop and test code while official or team-built hardware-in-the-loop systems are unavailable.
Additional resources:
The toolkit is licensed under the PolyForm Noncommercial License for teams, schools, nonprofits, and other qualifying noncommercial users. The written guides use the CC BY-NC 4.0 license. Commercial licensing is available separately.
Questions can be submitted through GitHub Discussions. Bugs and documentation errors can be reported through GitHub Issues. Security reports should use the private process described in the project’s security documentation. Support is community-based and provided on a best-effort basis.
[un]labs is a technology advisory and engineering practice focused on disruption at the edge of AI and engineering.
We invent, then harden the invention, with the rigor that regulated and performance-critical systems demand—for domains where the cost of being wrong is real.
For more information, visit https://unlabs.co.
Chris Kelley
Co-Founder and Managing Member
[un]labs
ckelley@unlabs.co
FIRST®, FIRST® Robotics Competition, and FRC® are trademarks of For Inspiration and Recognition of Science and Technology (FIRST). WPILib and WPI are marks of their respective owners. Claude and Claude Code are marks of Anthropic. Unlabs, [un]labs, and the Unlabs logo are trademarks or service marks of Unlabs, LLC. All other product names, logos, and brands are the property of their respective owners and are used here only to identify the software this document describes. Use of them does not imply any affiliation with, endorsement by, or sponsorship by their owners.
Unlabs, LLC is not affiliated with, endorsed by, or sponsored by FIRST, Worcester Polytechnic Institute, the WPILib project, or Anthropic.
FIRST has said that teams may use AI to assist with robot code and other content. In a post dated November 1, 2023, FIRST’s Chris Rake wrote that teams using AI in this way “must provide proper credit and attribution, and respect intellectual property rights and licenses,” and that judges have been instructed not to discredit a team or rank it differently based on the tools it used. FIRST also wrote that it may revisit the subject in future seasons.
That post is guidance, not the 2027 game manual, which was not yet available when this was written. Teams should read the 2027 manual and FIRST’s current guidance when they are published, and decide with their mentors how to credit the AI tools they use.
Source: https://community.firstinspires.org/expanding-the-first-toolbox-with-artificial-intelligence
It is an AI-assisted development toolkit for student FRC programmers. It runs within Claude Code and works with a team’s existing WPILib project.
The toolkit helps students define intended robot behavior and create, explain, test, simulate, debug, review, and prepare related Java code.
No. This is an alpha release, version 1.0.0_Alpha-7, available for use now.
The toolkit’s maturity is linked to the maturity of WPILib 2027, which is currently in alpha; WPILib has not published a 2027 beta. The version number carries the number of the WPILib pre-release the toolkit was built against. This release supports WPILib 2027.0.0 alpha 7 and will be updated as new WPILib 2027 releases are made available.
Early availability gives teams time to learn the workflow, test it in software-only environments, and provide feedback before the 2027 competition season.
No. The toolkit is installed into an existing WPILib project and used within Claude Code. It does not replace WPILib, the Java compiler, Gradle, the WPILib desktop simulator, or a team’s normal project tools.
It can help create code from a student’s requirements, but the process is more structured than a single prompt.
The behavior-first workflow asks the student to define the intended behavior, limits, failure cases, and evidence of success. The student agrees to those conditions before implementation begins.
No. The toolkit is designed to help students who are still developing their programming and WPILib skills.
It does not remove the need to learn. Students must understand the intended robot behavior, review the proposed work, interpret test and simulation results, and participate in safe physical testing.
No. It can provide repeatable development and review workflows when an experienced software mentor is not immediately available. A mentor or other qualified person remains important for safety decisions, electrical and mechanical integration, permissions, and physical deployment.
The student decides what the robot should do and approves the conditions used to judge the result. The toolkit supports implementation and verification of that decision.
Deployment remains a deliberate human action.
The toolkit is designed to produce Java code for projects that depend on WPILib 2027.
When a proposed class or import is uncertain, the toolkit can compile a small probe against the project’s actual dependency tree. This checks whether the referenced API exists in the installed libraries.
It does not mean that WPILib, WPI, or FIRST has certified or endorsed the generated code.
No. Compilation, automated tests, simulation, and review can detect many defects, but they cannot establish that all code is correct.
The team must still review the work, inspect the robot, test hardware under controlled conditions, and follow its safety procedures.
Students can define behaviors, create code, run laptop-based tests, check WPILib dependencies, review code, and use supported features of the WPILib desktop simulator.
This lets software work continue while the robot is incomplete, under repair, or being used by another group. See the additional documentation at https://unlabs.co/projects/unlabs-ai-toolkit-frc-2027/ for ways you can use off the shelf hardware to test in a physical environment earlier.
The /test workflow creates one named test for each condition identified in the agreed behavior. It then maps every condition to its test.
If no test covers a condition, the report identifies that condition as uncovered. The workflow does not call the work complete while an agreed condition remains uncovered.
Simulation can show how supported software behaves in the simulated environment. It can expose incorrect logic, state changes, command interactions, and some control behavior.
Simulation does not prove that the real mechanism is safe, correctly wired, correctly configured, or able to operate under physical load.
It uses several forms of evidence:
These methods reduce reliance on plausible-sounding answers. They do not eliminate the possibility of an incorrect answer.
It records the results of compilation, the current test run, the simulation stage, compiler warnings, and the working-tree check. It also records the number of tests that executed.
The verdict reports what was checked and what the result does not prove. It is not a certification that the physical robot is safe or match-ready.
The normal workflow does not deploy code automatically. It checks the required evidence and then provides the deployment command for a student to run.
If the evidence is stale or incomplete, the command is withheld and the reason is shown.
No. The project includes deny rules for common sensitive files, build files, and common forms of the deployment command. These rules are safeguards, not a complete security boundary.
The project documentation identifies what the rules enforce and where their coverage ends.
The installer is designed not to overwrite an existing file. When it finds a different version of a file, it leaves the existing file unchanged and reports the difference.
Teams should still use version control and first evaluate the toolkit on a branch.
The recommended sequence is:
A small subsystem with visible behavior is a good starting point. An intake is one example.
The student can define the motor’s active and idle behavior, state what should happen when a command ends, create tests, and observe the simulated motor output.
The repository includes a public limitations document. Teams should review it before adoption and again before taking a toolkit update.
The session-start check reports the newer version. A release that addresses a security issue is marked as a security release and directs the student to involve a mentor.
Teams can disable the update check. It also remains silent when it cannot reach GitHub.
The toolkit is available for free under the PolyForm Noncommercial License for qualifying noncommercial use. The guides use the CC BY-NC 4.0 license.
Commercial use is licensed separately.
Users can ask questions in GitHub Discussions and report bugs or documentation errors through GitHub Issues. Security concerns should be reported privately through the process in the repository’s security documentation.
Support is community-based and best effort.