Who Taught Us to Fear Our Own Leverage?
A student in our robotics lab recently said they ought to start recording ideas they wanted to explore for robot vision.
I agreed. I suggested putting those ideas into the agent and having it maintain the record. Later, the student could ask what remained unexplored, revisit an earlier thought, or brainstorm a next experiment using the accumulated notes.
The student insisted on using the dry-erase board.
Then came the sentence that stopped me:
“I don't want to use AI.”
I had not asked the student to surrender an opinion, fake an accomplishment, or let a machine decide what the robot should do. I had suggested using an available assistant to preserve and develop the student's own ideas.
There is nothing wrong with a whiteboard. We can use both. The revealing part was the categorical refusal: not a discussion of which method suited which purpose, but an objection to using AI at all.
Nor was this a restriction imposed by the lab. I have encouraged these students to use agents. The limitation, in these encounters, is coming from the students themselves.
That is the problem I want to confront. What has our culture taught people about these tools that makes a young person reject useful leverage almost as a matter of identity? And why are the institutions charged with preparing them for the future doing so little to replace that reflex with practical competence?
We should be teaching people to command powerful tools. Instead, too often, we are leaving them to regard their own increased capability as something suspect.
I am not talking about asking a chatbot questions
The distinction matters because much of the public argument is still stuck several steps behind the technology.
A conversational system can explain how to do something. An agent can pursue the task: inspect files, use tools, run commands, examine results, revise its approach, and produce an artifact or a change in a real system. Its abilities depend on the environment, permissions, and tools it has been given.
The dividing line is not whether there is a chat window. A chat interface can be the front door to an agent.
Products that began as chatbots are acquiring more of these capabilities. OpenAI now describes ChatGPT Work as an agent for longer, multi-step work and finished deliverables. Its cloud browser can interact with websites on a separate cloud computer. Other tools work directly in a person's project environment.
One web search does not by itself constitute substantial delegation. The more important transition is from “tell me how” to “carry this through, show me what you did, and give me something I can use.”
Someone can have extensive experience chatting with AI and very little experience directing an agent through actual work. Chatbot-use statistics cannot tell us how comfortable people are with that second activity. This essay is about the second activity.
The difference is access to your actual world
I increasingly use agents inside my own ecosystem, predominantly through OpenCode, and sometimes through Codex. They are useful not merely because they can produce plausible text, but because they can work with resources I have authorized them to access.
This blog is an example. It runs on my local network. An agent helped create this article's draft, make its illustrations, upload the assets, save the post in Ghost, and inspect the preview. It could do that because it had a working route to the relevant system and enough context to complete the job.
That is a different kind of assistance from receiving an essay in a browser and then performing every administrative step myself.
A cloud-hosted agent with no route or credentials to my local services cannot simply reach in and manage them. Connections and permissions have to exist. Some products can bridge that gap, and Work also supports local access in supported desktop configurations. The point is not that one brand can never do what another can. The point is that useful agency depends on the working environment, not just the model's ability to talk about the task.
The same principle applies to a robotics project. An agent with access to the repository, documentation, test commands, and maintained project notes can help carry work forward. A conversation disconnected from those resources leaves much more of the burden on the human.
Project memory also has to be made real. “Remember this” should mean saving something durable and inspectable, not hoping a long conversation will remain available forever. The agent needs a place to put the record, and the team needs to know where it is.
The restriction is already inside the room
It would be simpler if I were fighting a written prohibition. Change the policy, provide the tools, and proceed.
But in these encounters, permission already exists. Encouragement already exists. A useful task is right in front of us. The refusal arrives anyway.
That makes this more than an access problem.
I cannot read a student's mind. Dislike, a bad prior experience, anxiety about dependence, uncertainty about the tool, and social pressure are different explanations. None should be silently substituted for evidence.
But we should examine the messages surrounding these students. If AI is repeatedly framed as cheating, laziness, synthetic garbage, or a threat to being a “real” creator, it should surprise nobody when some students absorb a prohibition broader than any actual rule.
No coordinated conspiracy is needed. A culture can produce self-policing through repetition. Eventually, a tool is rejected before its usefulness is considered.
When people decline their own leverage without giving it a serious trial, making the software available has not finished the educational job.
A keyboard is not a learning objective
Another student—a brilliant member of our coding group—wants to learn Java. I encouraged him to lean on the agent: have it generate code with explanations, study the result, copy useful parts, ask questions, and work through what the program does.
He and another coder have nevertheless insisted on manually typing the syntax.
I have been programming for decades. Copying, adapting, and reusing code are not alien practices smuggled into the profession by AI. They are ordinary parts of software development. The obligation is to respect licenses, understand what matters, and verify that the code does the job—not to establish personal authorship of every keystroke.
Typing can be a useful exercise. It is not a universal requirement for learning, and it should not become an unquestioned tax on every project.
Nor is copying automatically understanding. An agent's explanation can be wrong. The test is whether the student can reason about the code, predict a change, recognize a failure, and use the available tools to investigate it.
Typing is not proof of understanding. Pasting is not proof of ignorance.
A friend of mine, also a programmer of many decades, tells me he has not manually written a line of code in more than six months since adopting coding agents. He also tells me he is accomplishing more than he expected to accomplish in that period.
That is his account, not a controlled productivity study. But it describes the opportunity clearly: the work did not disappear when manual code entry did. More of his effort moved toward directing, evaluating, and accomplishing.
We keep climbing the abstraction ladder—then declare the next rung illegitimate
Computing has advanced by letting us express more intent with less mechanical labor.
We moved beyond punched cards. We built high-level languages, interpreters, libraries, massive SDKs, development environments, and browsers. We stopped requiring each programmer to reconstruct every layer beneath the task at hand.
Typing Java is not literally programming with punched cards. The comparison is about an attitude: treating a familiar layer of manual work as the last legitimate one, and the next useful abstraction as a betrayal.
Agents are not simply compilers. They can introduce unpredictable mistakes, choose bad approaches, and sound persuasive while failing. That changes the verification work. It does not establish a moral obligation to avoid them.
The profession has never been chiefly about finger movements. It is about making systems do useful things under constraints.
If a person can specify the goal, guide an agent through implementation, examine the result, and get a reliable system working, the relevant question is not whether the keyboard suffered enough.
A finite robotics season is not an infinite tutorial
Our time in the lab is limited. That fact cannot be wished away by announcing that every intermediate step would be educational.
Many things are educational. We cannot do all of them before the time runs out.
A robotics project must balance skill development with integration, testing, and actual accomplishment. If we spend the available hours manually reconstructing what an agent could help produce and explain, we may never reach the experiments that make the underlying concepts meaningful.
I want students to experience the satisfaction of getting something substantial to work. Not a deceptive demo they cannot explain. A robot behavior, a vision experiment, or a subsystem they helped direct into existence and can investigate further.
Completion creates new questions. Why does detection fail under different lighting? What causes the delay? Which assumption was wrong? What happens if we change the threshold? Those are opportunities to learn through a working system, rather than spending the season approaching one.
An agent can draft a component and its tests. The student can inspect the decisions, run it with controlled inputs, request an explanation of a failure, change the design, and compare results. That is not the absence of intellectual work. It is a different allocation of it.
A project that never reaches meaningful testing has educational costs too. We should stop counting only the risks of using powerful assistance and start counting the opportunities lost by refusing it.
Readiness means having your tools ready
Students should be able to respond when something fails. The question is what preparedness ought to include.
It should include a working agent setup: access to the right repository, clear project notes, relevant logs, known test commands, and a way to evaluate a proposed repair. Setting that up before a problem occurs is an engineering responsibility, not a shortcut around one.
It should also include known-good builds, rollback procedures, local documentation, and basic diagnostic ability. Connectivity can fail. Accounts can reach limits. Agents can be unavailable or wrong. A single dependency with no fallback is not a preparedness plan.
Competitions have operating rules and network constraints, and teams must follow the rules that actually apply. I am not asserting that FTC currently requires unaided manual debugging. My argument is about the standard we should teach: can the team diagnose the problem and restore a working system using its permitted tools?
Reading a log, identifying the relevant subsystem, directing an agent to investigate, examining the patch, and validating the result are debugging skills. They do not cease to count because assistance is involved.
The goal is resilience and command—not a ceremony in which we temporarily pretend our best tools do not exist.
We do not need to wait for an agent in every pocket
More capable agents on personal devices would make this kind of assistance easier to keep close at hand. Exactly when a particular phone will run a particular level of intelligence entirely on-device is not a sound basis for delaying everything we can do now.
Where the model runs and where the work happens are separate questions.
An agent can already work in a local project while using a cloud-hosted model. A cloud agent can work in a managed environment and interact with authorized services. Fully local inference is another arrangement, with its own hardware and capability constraints.
The practical skills transfer: define the outcome, preserve context, manage access, inspect actions, test results, and recover from failure.
Students can begin acquiring those skills with today's tools. Waiting for a future device to make the lesson unavoidable is not forward-looking education.
Institutions must teach competent delegation, not merely tolerate it
It is not enough for a school to say, “AI is allowed,” while leaving its students with the impression that using it makes their work less legitimate.
The obligation is more active than that. Show what these systems can actually do. Let students practice on meaningful tasks. Teach them to challenge an agent, retain records, examine changes, and take responsibility for a result.
Do not make the whole subject a lecture about cheating. Do not mistake a discussion of chatbot-generated essays for preparation to direct agents in a technical environment.
And do not celebrate a reflexive “I don't use AI” as though it were automatically evidence of independent thought. A reasoned rejection of a tool for a particular task is one thing. A categorical refusal to explore useful capabilities is another.
There may be concrete barriers—cost, accessibility, account rules, missing setup, or confusion about what is permitted. Address them. They are problems to solve, not reasons to abandon the teaching of a consequential capability.
This does not require allegiance to OpenCode, Codex, or any vendor. It requires understanding a changing class of tools well enough to choose and direct them.
What is the point of an institution that claims to prepare students for the future if it leaves them to arrive there already embarrassed to use its instruments?
Who gets leverage, and who gets lectures?
There is a broader social question here.
Large organizations have money, staff, infrastructure, and increasing opportunities to automate. Individual people have much more limited time and support. Agents can put some previously expensive forms of assistance within an individual's reach.
That does not magically erase unequal power. It makes access to practical competence more important, not less.
A culture that normalizes algorithms directing people's attention while stigmatizing people directing their own computational assistance has its priorities backward.
Nor should distrust of a vendor become a prohibition against developing the capability. Demand better privacy, sensible permissions, portability, and clear terms. Choose different products. Keep your records and artifacts in forms you can retain. Do not confuse surrendering all access with defending your independence.
We should be particularly wary of any outcome in which institutions become more capable while ordinary people are congratulated for staying unassisted.
A better mandate: show what you can accomplish and defend
The educational expectation I want is not “never type code yourself.” It is “learn to use powerful assistance deliberately, and be answerable for the result.”
For a robotics team, that could look like this:
- Keep a durable project record. Have the agent save ideas, decisions, questions, and experiment results in team-controlled files. Revisit those records instead of repeatedly starting from nothing. A whiteboard can feed that record; it need not compete with it.
- Delegate a bounded piece of real work. Supply the repository, constraints, and success criteria. Ask for an implementation, an explanation, and a way to test it.
- Interrogate the result. Have the student explain key decisions, identify assumptions, and change a behavior. Challenge the agent's reasoning rather than treating its explanation as a certificate.
- Validate before physical operation. Use simulation or controlled tests where available. A suggested patch is not permission to actuate hardware. Follow the lab's safety procedures and keep people in charge of deployment and movement.
- Prepare to recover. Maintain known-good versions, inspectable changes, and a documented route back when the proposed fix fails.
- Finish something worth discussing. Evaluate the working result, the student's understanding, the problems encountered, and the next experiment—not the number of characters manually entered.
This is a proposed direction, not a description of a manual-coding rule I have imposed on the lab. I want the students to discover how much more they can attempt when they stop treating assistance as disqualification.
Use age-appropriate services and authorized accounts, follow school and competition rules, and keep private information out of tools that have not been approved to receive it. Those are working boundaries. They are not a philosophical case against using agents.
Stop mistaking refusal for independence
These students are capable people. That is why watching them voluntarily narrow their own reach is so frustrating.
I am not asking them to stop thinking. I am asking them to use tools that can help carry their thinking into the world.
The difference is enormous.
We should demand more of the culture surrounding them: less moral theater about unaided effort, less confusion between cheating and delegation, and far more practical instruction in how to direct a system without surrendering judgment.
Give students the taste of accomplishing something they could not have completed with the same time and resources before. Let that accomplishment open the next question, the next skill, the next project.
Refusal is not automatically independence. Sometimes it is simply a learned boundary that nobody has yet taught us to question.
The future will not reward us for having performed every intermediate step by hand. We should be preparing people to choose the right tools, command them intelligently, and build something worth having.
There is no virtue in leaving that leverage untouched while the time to do something meaningful runs out.
Sources, authorship, and scope
The lab encounters and the account of my programmer friend are personal accounts, not a survey of all students or a controlled study. The argument about cultural conditioning is an interpretation; it does not establish a particular student's motives or a coordinated campaign. No unaided-debugging requirement is attributed to current FTC rules.
Current product descriptions were checked against OpenCode's documentation, OpenAI's ChatGPT Work and Codex documentation, and its cloud-browser documentation. Features depend on permissions, configuration, plan, and availability. No chatbot-use survey is offered as evidence of agent adoption.
This article was developed with an AI agent from my observations, examples, and editorial direction. The accompanying original illustrations explain metaphors and workflows; they are not empirical charts.