Screaming at the Silicon

Archive - Fedi

I Prefer to Use My Brain

December 7, 2025

"I prefer to use my brain for that." is the devastating reply my friend responded with after I sent them a procedural generator for the description of random characters. His response was both true and tinged by the non-stop suggestion that people should use generative AI (large language models) to mimic creative labor. I stashed that glib reply in my mind for when I next received the suggestion to use AI to do a task I'm well capable of (and enjoy) doing on my own. I was not expecting that the next person to be cut down by this reply would be myself.

While I think I will always prefer writing systems that run behind the scenes, I am currently working at becoming competent with the patterns and tools of front-end development flows. There are too many ideas I want to take a stab at to not build front-end muscles. The day job has granted me an opportunity to get up to speed with React. After a few weeks on React, I decided that programming in my leisure time should be something I enjoy. Sometimes you luck out and enjoy the tools at work, and sometimes you don't. I went in search of something else and remembered enjoying Vue when I dabbled with it a half-decade ago. So, I spun up the Vue docs and went through the initial setup. It was the exact amount of tool I wanted with more built-in utilities than going plain HTML, CSS, and Javascript and fewer architectural decisions preordained about the application itself from simply choosing Vue as a framework.

With Vue I have been making steady progress on a web application that presents character data for this play-by-post tabletop role-playing game the aforementioned friend and I are writing. I got through the creating the visual presentation by using the Vue docs, Lachlan Miller's Design Patterns for Vue.js, and searching blogs around the web. When it came to the data layer, the priority was being able to create & render character information in a local first manner. As there are only five of us who will use this at the moment, our non-functional requirements are pretty sparse. If we need to share & update data, this is trivial to handle manually. Noting our sparse requirements and wanting something that could handle these JSON blobs with minimal fuss, I landed on IndexedDB -- it does everything we want and it is bundled in the browsers across all the devices we use.

The next step was to create a service in the application that would perform CRUD operations against IndexedDB. The sheer number of reference implementations online made this step stunningly straightforward. Before integrating this service into the application, I wanted to do some basic verification that the CRUD operations would work. On this day, I did not desire to learn the best practices for writing integration tests in a Vue application. I settled on making a debugger component with a submit button to persist each entry with a unique ID, allow me to delete each item in the database, and show a list of entries. I would import this into App.vue , quickly add some entries, and validate that against the developer tools view of IndexedDB.

Before I went down the path of writing a debugger component, a thought bubbled from the depths: this scenario is one place where generative AI can be useful and presents minimal risk to the overall system. Using a large language model (LLM) would be trivial to set up because I still had Cline on my personal system from when there was a big push at work to integrate AI into my workflow (how it landed on my personal machine is a post for another time, but Cline in my IDE was the approach I came upon that made generative AI still feel like ceding my hard-won skills to the best guessing machine but more like a developer tool). There I am with Cline, adding the files to the context window, and I submit a prompt that said something to the effect of "generate a standalone debugging component that does CRUD operations using the provided service/indexdb.js implementation."

I have never let Cline work in "Act" mode because if anyone is going to rm -rf * my system, it will be me once I have decided it is time to set the silicon alight and wander into the woods never to think about computers again. I read through the suggested code, tweaked a few style preferences I immediately knew I would care about while testing, created the component file, and then imported it. After annpm run serve ,I'm off and testing the database operations.

The debugger component just works. I have done several experiments with AI every few quarters because every few quarters I hear a previously skeptical developer say, "It's good now." The results in every previous test have been unimpressive. I was genuinely surprised that I had to spend zero time tweaking anything to get the generated code working. Sure, I did perform a pass of the code and do some minor tweaks, but nothing that would have enabled it to work when it otherwise would not have. This has not happened on any prior test I've done with LLM-generated code.

I complete my test of the IndexedBD service I wrote and should be set to begin adding that functionality into the application. I should be excited by the progress, but something feels wrong about this whole endeavor, and I lose my motivation to continue working. As I am sitting at the desk reflecting on why a pall hangs over this success, it comes to me, "Oh yeah, I prefer to use my brain for that." Generative AI did speed me up here, but this is a hobby project. There is no deadline; no one is demanding me to work faster and get this to production. In fact, my explicit goal is to get decent at front-end development using a modern framework. Even though I used generative AI in a spot that could work within its confines and kept it from being a part of the actual application code I am writing, I robbed myself of opportunity.

Instead of prompting for throwaway code, I could have spent the time making a reusable debugger component that I could take across projects that was tailored to my workflows. In doing so, I would have learned more about IndexedDB, Vue, and front-end developer tools and entirely avoided the laundry list of externalities incurred by AI use. I did not do that. I took a route around doing a manual integration test. It is not necessary for generated code to grant me permission to skip writing a test; I could have committed to skipping that task and continued working. Directly integrating the IndexedDB calls into the application and then testing manually once that was complete would have had the same impact. Instead, I have theoretically reusable throwaway code for testing IndexedDB in the browser and am entirely missing the part where the service is integrated into the application.

The end result of this is that I removed the Cline integration from the IDEs of my personal machines and have been working up the spirit to get back to a project that I was excitedly working on. When the push next comes around to integrate AI into my workflow, that will exclusively happen on the device owned by those pushing for it. If integrating a tool into my process does not work in the instance I am asked to adopt it, I do not need to find the problems that this solution solves. I prefer to use my brain, but I don't need to use it to find the business case for widely deployed large language models while simultaneously de-skilling myself.

Further Reading

https://www.wiley.com/en-hk/Is+AI+Good+for+the+Planet%3F-p-9781509547951
https://www.wheresyoured.at/the-case-against-generative-ai/
https://economics.mit.edu/sites/default/files/publications/Harms%20of%20AI.pdf