It is late in the build season. A student is trying to understand why an autonomous routine behaves perfectly in simulation but drifts on the real robot.

A few years ago, the next step might have been searching documentation, reading forum posts, asking the programming lead, or waiting for a mentor. Today, the student can give an AI system the relevant code, describe the behavior, share a section of a log, and ask for possible causes, competing hypotheses, and an experiment to run next.

The AI might be wrong. The student still has to investigate, test, and decide what to trust. But they may have moved from “I don’t know where to start” to a testable engineering hypothesis in minutes.

The same shift is happening across FRC. Students can use AI to understand unfamiliar concepts, prototype software, analyze telemetry, explore design alternatives, work through documentation, and learn beyond their traditional sub-team boundaries.

That creates a bigger question than whether students should be allowed to use AI:

What should an FRC team look like when powerful AI assistance becomes a normal part of the engineering environment?

That is the question behind this series.

Why I Am Writing About This

I approach this topic from two worlds that are increasingly converging.

I have spent my professional career in software engineering, building large-scale systems and working with AI and intelligent technologies. At the same time, I am deeply involved with FIRST. I mentor students on an FRC team, serve on the FIRST Washington Board of Directors, and have served as an FRC judge at multiple levels of competition.

These experiences give me different views of the same transition. In the technology industry, AI is changing how engineers learn, design, write software, analyze systems, and solve problems. In FIRST, I see students and mentors beginning to wrestle with many of the same questions: What should students use AI for? How much help is too much? What does student ownership mean when an AI system can generate significant parts of the work? How should mentors teach when answers are available almost instantly?

I am not writing this series in any official capacity or on behalf of FIRST, FIRST Washington, my FRC team, or any other organization with which I am affiliated. These are my personal views on what an AI-Native FRC framework could look like and how teams might think about the opportunities, responsibilities, and engineering practices that come with AI.

The idea at the center of this series is simple:

AI should amplify student agency, not substitute for it.

AI Changes More Than the Tools

FRC teams have adapted to major technology shifts before. Better control systems, vision, simulation, telemetry, manufacturing tools, software libraries, and commercial components have steadily expanded what high school students can build.

AI is different because it changes not only what students can build. It changes how students learn to build it.

An AI system can explain an unfamiliar concept, help navigate documentation, critique an idea, compare alternatives, analyze data, or suggest experiments. That lowers the cost of exploration and makes it easier for students to enter unfamiliar technical areas. That is valuable in FRC, where students are learning while simultaneously trying to build a competitive robot.

But faster output is not automatically better learning or better engineering. Working code does not prove understanding. A quickly generated CAD model is not automatically a good design. An analysis is only useful if someone understands its assumptions and knows whether its conclusions are trustworthy.

The robot matters. Competitive performance matters. Productivity matters. But in FRC, the robot has never been the only outcome. The students are also the outcome.

Move Beyond “Which Tools Are Allowed?”

When a new technology appears, the first instinct is often to establish boundaries. Can students use generative AI? Can it write robot code? Can it help with CAD? Is an AI coding agent acceptable?

Teams may need practical guidelines, especially where safety, reliability, privacy, cost, or competition rules are involved. But a tool-by-tool policy is unlikely to be a durable answer.

AI will increasingly become part of the tools students already use, including IDEs, CAD systems, simulation environments, cameras, data-analysis platforms, and robotics software. Over time, drawing a clean boundary around “using AI” may become as difficult as drawing one around “using the internet.”

A more durable approach is to focus on the student and the engineering process.

Does the student understand the work? Did they make meaningful decisions? Can they explain why the system was designed this way? Do they understand likely failure modes? Was the result tested? Can they debug it? Are they accountable for what ultimately goes onto the robot?

Those questions remain useful regardless of which tools were used. The goal should not be to minimize AI use. It should be to maximize student learning, judgment, and ownership.

Student Agency Is the North Star

Student agency is not the same as requiring students to perform every task manually.

A student can type every line of code and still have little ownership if they are simply following instructions. A student can also use significant AI assistance while still owning the engineering problem if they understand the system, evaluate alternatives, make the important decisions, verify the result, and take responsibility for what happens next.

Used well, AI can expand that ownership. A mechanical student can learn enough about controls to participate in a broader engineering discussion. A programmer can understand a mechanism well enough to ask better questions about its design. Students can cross boundaries that previously required much more time or access to specialized help.

AI does not have to reduce what students do. It can increase the range of problems they are capable of understanding and owning. The wrong measure of AI adoption is how much work we can remove from students. The better measure is how much more students become capable of doing well.

What This Starts to Change

Most FRC teams organize work around specialties such as mechanical, CAD, electrical, programming, strategy, and scouting. Those specialties matter because students need places where they can develop real depth.

But specialization can also become a boundary.

• “That is a programming problem.”
• “Ask mechanical.”
• “I don’t know anything about electrical.”

AI lowers some of the barriers that reinforce those divisions. It does not eliminate the need for expertise. In fact, expertise becomes even more important when someone must recognize whether a convincing AI-generated answer is actually correct.

But sub-teams can remain centers of expertise without becoming boundaries of permission.

The same shift affects mentoring. As information becomes easier to access, mentors become even more valuable for developing judgment. Instead of only answering “How do I do this?”, more mentoring can focus on questions such as: What problem are you solving? What assumptions are you making? What would make this fail? How will you test it?

And perhaps the most important one:

How do you know?

AI can propose an answer. Engineering still requires someone to decide whether that answer deserves to be trusted.

Productivity Is Valuable, but It Is Not the Goal

Productivity matters in FRC. Students balance school, activities, limited mentor time, manufacturing constraints, competition schedules, and limited access to the robot.

If AI helps a student understand an unfamiliar API faster, identify an anomaly in a log, or explore several ideas before committing to one, that is useful. But productivity should serve larger outcomes.

An AI-Native FRC team should optimize together for student learning, student ownership, engineering quality, and competitive performance.

Those goals will not always align perfectly. The fastest way to finish something may not create the best learning experience, and the right level of AI assistance will vary by student, task, and consequence. That is why the better question is not: How much AI should we use? It is:

What level of assistance helps this student own this problem responsibly?

The Robot Is Not the Only Thing That Must Change

Every generation of FRC students inherits better tools than the generation before it. AI is part of that progression, but its impact may be different because it can expand not only the capabilities of the robot, but the capabilities of the student building it.

Teams can use AI primarily to produce the same work faster. Or they can use it to help students understand more, explore further, cross technical boundaries, test more ideas, and take responsibility for harder engineering problems.

That second possibility is much more important.

As AI makes building easier, students should spend more time deciding what is worth building, why it should work, what could go wrong, and how they will prove that what they built actually works.

That may require us to rethink how we organize teams, develop expertise, assign ownership, mentor students, and define what good engineering looks like. One of the first places to examine is a structure that has shaped FRC teams for decades: the sub-team.