The Point Where I Used to Stop
For most of my life, I assumed coding belonged to other people. It was for developers, programmers, and those who understood what all those brackets and symbols meant. I had taken AP Computer Science in high school, but that experience only reinforced the idea that coding was not for me. I remember making it through “Hello, World!” before becoming lost somewhere between functions, variables, and whatever came next. Whether “Hello, World!” was an assignment, a function, or simply a warning sign, I am still not entirely sure.
After that, I stayed away from coding. I could appreciate what technology made possible, and I had dabbled with formulas and macros, but I still did not see myself as someone who could build anything with code.
What I have never been good at accepting, though, is an inefficient process. When I run into a repetitive administrative task that feels more complicated than it should be, I usually start looking for a better way to do it. I search the web, try different features, look for extensions or add-ons, and, more recently, ask AI for ideas.
Quite often, I eventually reach the same answer: the solution involves code. That is usually where I stop. I still cannot sit down with a blank screen and independently create a Google Apps Script, Google’s tool for using code to automate tasks across apps such as Sheets, Docs, Drive, and Gmail.
What I can do is identify a frustrating process, explain what I want to happen, follow clear directions, and keep asking questions when something does not work. As I learned during this experiment, that combination can be enough to get surprisingly far.
One day, I wondered why I was stopping at that point. If AI could help me find the solution, could it also help me write the code? That question became an experiment.
The Annoying Problem That Got Me to Try
My experiment grew out of a task that was not especially difficult. It was simply annoying.
Whenever I needed to share materials with a principal, colleague, or student, I typically would create a folder, name it, grant access, copy the link, send it, and then keep track of where everything was located. Doing that once was manageable. Doing it over and over was the kind of small administrative task that quietly eats away at your time.
Normally, I would have searched for a tool that could help. This time, I described the entire problem to Gemini instead. I explained that I wanted to start with a spreadsheet containing names and email addresses, create an individual folder for each person, assign the appropriate access, and have the folder link automatically written back into the spreadsheet for my reference.
Gemini generated the code, but the code by itself was not what made the experiment possible for me. It also showed me where to open Apps Script, where to paste the code, what I needed to change, and what to click.
When an error appeared, I copied the message into Gemini and asked what it meant. When the script did something I did not expect, I described what happened and asked it to fix the problem. I did not suddenly understand programming; I simply kept following the directions and asking the next question.
Eventually, the tool worked. I could identify a main folder, add names and email addresses to a spreadsheet, and run the script. It created an individual folder for each person, assigned access, and placed the link back into the spreadsheet. The same basic idea could also be adapted to create individual Google Docs, Sheets, or Slides from a template.
Of course, there are other ways to solve a problem such as this. Extensions, add-ons, and tools in the Google Workspace Marketplace may already do some or all of these things, and sometimes may even be the better solution.
What was different this time was that I was not trying to fit my workflow into someone else’s tool. I started with the workflow I wanted and built the tool around it. I could decide what information appeared in the spreadsheet, how folders were named, what the script did, and what information it returned to me.
For a developer, this may be an ordinary project. For me, it represented a significant shift. I had moved from thinking, “There must be a tool for this somewhere,” to realizing, “Maybe I can build the tool I actually want.”
Before using it with real recipients, however, I tested it with sample accounts, checked the folder locations, and verified the permissions. A mistake in an email address or sharing setting could give access to the wrong person, so the ability to automate something did not remove the need to check my work. I also asked a friend who teaches computer science to review both the tool and the code to make sure I was not missing anything important, and I made sure everything aligned with my organization’s policies before considering it ready to use.
Once I Built One Tool, I Started Seeing Other Possibilities
Getting the first script to work changed the way I looked at other repetitive tasks. Instead of immediately accepting a cumbersome process, I wondered whether I could build something to make it easier.
One example involved receiving a large master spreadsheet containing information that needed to be separated and distributed to different people. The manual process required filtering the file, copying the correct rows, creating separate documents, reviewing each one, and preparing the corresponding emails.
I asked Gemini whether a script could handle some of those steps. Together, we developed a tool that could separate the spreadsheet into recipient-specific files and prepare the corresponding emails. Rather than spending my time repeatedly filtering, copying, and creating files, I could spend more of it reviewing the results.
This example also showed me where the limits of my experimentation needed to be. An incorrect filter could place the wrong information in a file or send it to the wrong recipient. I would avoid using an AI-generated tool such as this with student-level data because the consequences of an error could be significant. I would limit it to information that could be safely distributed and that complied with my organization’s policies.
I also preferred to have the script create email drafts rather than automatically send anything. That gave me the opportunity to check the recipient, attachment, subject line, and message before anything left my account. Saving time was useful, but not at the expense of judgment.
Another experiment came from a similar frustration. I often work from spreadsheets containing names, roles, schools, and email addresses, so I wondered whether the spreadsheet itself could become a more useful communication tool.
With Gemini’s help, I created a script that allowed me to select people from the spreadsheet and decide how I wanted to contact them. Depending on the situation, I could place recipients in the To, CC, or BCC field or create an individual draft for each person. The subject line and message could also be pulled directly from the spreadsheet.
None of this is revolutionary technology, and that is actually part of the point. I was not trying to create the next great software platform. I was solving small problems in my own work and shaping each solution around how I actually worked.
The Skill Was Not Really Coding
Someone who knows how to code would already understand functions, debugging, onOpen(), and many of the other concepts that still feel unfamiliar to me, and they would almost certainly produce cleaner and more sophisticated code than I could. But that was not the expertise I brought to the experiment.
What I brought was a clear understanding of the problem, a solid grasp of the workflow, and a sense of what I wanted to happen. I could recognize when the result was wrong, describe the desired outcome, follow instructions, test what AI produced, and explain what needed to change.
Those abilities are not unique to programmers. Educators and school leaders use these constantly. We identify problems, explain processes, coordinate people, review information, and revise plans when something does not work.
Working with AI made me realize that those skills could also be part of building a technical solution and could help democratize solutions to everyday problems. I did not need to understand every line of code before I could experiment with it, but I did need enough understanding to test the tool, question the results, recognize the risks, and know when I was moving beyond what I should attempt on my own.
AI Did Not Make the Problems Disappear
Of course, the experience was not as simple as telling Gemini what I wanted and immediately receiving a perfect tool.
Sometimes a column heading was wrong. Sometimes the script could not find the folder. Sometimes it created duplicate files or stopped before finishing. At other times, I received an error message that meant almost nothing to me.
Previously, that would probably have been the end of the experiment. This time, I went back to Gemini, described what happened, shared the error message, and asked what needed to change. Sometimes the repair worked immediately, while other times it introduced a different problem that required another round of questions.
I was still debugging. I just had help doing it.
AI did not remove the frustration of getting something to work, but it changed what happened when I became stuck. Instead of reaching the limit of what I knew and abandoning the idea, I had somewhere to take the next question.
The Guardrails Still Matter
None of this means that someone should copy AI-generated code, approve every permission request, and hope everything works. Schools and districts may have policies governing Google Apps Script, external AI tools, automated emails, data access, and file sharing, and those policies need to come first.
Privacy matters during development as well. Gemini does not need actual student names, email addresses, identification numbers, grades, or confidential district information to help me write a script. I can describe the structure of a spreadsheet, provide column headings, and use invented names and sample data.
Testing matters just as much. Before using a script with real recipients, I can test it with sample accounts, review permissions, inspect drafts, and confirm that the correct files were created. When the stakes are higher, having someone with more technical expertise review the code can provide another important layer of assurance.
AI can help me debug the code, but it cannot take responsibility for what I choose to do with it. That responsibility remains mine.
Moving Past the Place Where I Used to Stop
What surprised me most during this one-day experiment was not that AI could write code. I already knew that. What surprised me was what happened when I stopped treating code as an automatic dead end.
For years, my question was simple: “Do I know how to code?” Since the answer was no, that usually ended the conversation. AI has given me a different question: “Can I clearly explain the problem I am trying to solve?”
That shift matters. AI does not make me a developer, nor does it replace the expertise of people who actually know how to code. What it does is give me a way to experiment with everyday problems that I once assumed were beyond my technical reach.
I am still not sure I have fully recovered from AP Computer Science. But now, when the answer to a problem involves code, I do not automatically stop there. I might just ask the next question.
