Diagram generated by Codex
I don’t normally write about my side projects, but I think a recent one offers a useful lesson in applying Lean thinking to AI, or Lean AI.
Over the past year, AI has helped me build and manage a small web app that generates names according to precise etymological naming conventions unique to a particular fantasy world. Not quite Tolkien-level nerdom, but it’s pretty nerdy, with a fair amount of logical analysis. The app itself is lightweight, easy to maintain, and I wrote none of the code. My costs: a $20/month AI subscription, $11.08 annually for a vanity URL, and a considerable amount of my time.
Many people I see getting into AI really get into AI. Massive subscriptions, constant hardware upgrades, and 50- to 60-hour workweeks trying to automate 40 hours of work. I know people spending hundreds of dollars a month running increasingly sophisticated AI agents, building agents to manage other agents, and then introducing more agents to monitor those agents. It’s turtles all the way down.
Look, there’s nothing inherently wrong with any of this. Enthusiasts have always pushed technology beyond what the average person needs. We need those people. I’ve also spent countless hours overclocking PCs, so I understand the sensation. And other people spend thousands of dollars collecting Warhammer 40,000 miniatures, and even more hours learning the lore. There’s nothing wrong with that. Carry on, wargamer!
But people don’t do those things because they’re economical. There’s a big difference between what’s possible and what’s valuable.
I didn’t set out to use AI. I set out to make something useful. I wanted to generate lore-accurate names whose meanings and sources I could actually trace back to the published material. My first prototype was a Google Sheet. Today, it’s a fairly elegant, publicly hosted web app with its own etymological engine that automatically generates over a quadrillion variants (theoretically). However, the app isn’t dependent on AI, any particular provider, or an agent. And I approached its development the same way I’ve approached organizational improvement for years: through Lean thinking.
More recently, I rebuilt the application from the ground up with a new agentic setup. I started by configuring an AI agent through conversational prompts in a command-line window, establishing our end goal, working agreement, and a baseline of standards that we would continue improving. This formed the foundation of what’s commonly called an agent harness. But more importantly, it’s the same thing high-performing teams do when getting started, human or AI.
One of the more interesting parts of the project was how I performed the data extraction. Going through millions of pages of content looking for specific data points isn’t something any human is overly keen on doing, particularly this one. It’s also insanely expensive to have AI do it all. But here’s the thing: that repetitive activity doesn’t require intelligence. Using a human or AI for work that a simple script can accomplish is overprocessing waste.
Instead, I had my AI agent write scripts and launch workers to collect and organize data for review. Workers that consumed zero AI tokens. I had the agent independently process a sample of material and cross-check the scripts to validate their accuracy. After several adjustments, the scripts were correctly extracting the targeted data to an acceptable threshold, so we scaled to more workers.
The agent then monitored the workers, resolved errors or contacted me when necessary, and restarted scripts as needed. Periodically, it reviewed the collected data to eliminate false captures and confirm positive ones. During those long runs, my biggest responsibility was making sure my PC didn’t go to sleep.
This process took weeks, but once we had collected enough data and established the relevant naming rules, we began assembling the logic that would become the generator’s engine. I still had to find and validate certain sources, challenge interpretations, and make sure I was asking the right questions to produce satisfactory results.
This was also where the broader product development process began taking shape. We expanded our working agreements, coding conventions, review process, and tooling. There are standards that any maintained, publicly deployed web application should employ. Standards many of your engineers likely use today, such as version control, automated tests, CI/CD pipelines, and deployment verification.
These are things I knew to ask for. The agent offered recommendations, we discussed the approaches, and it configured the agreed solutions. Occasionally, I had to create an account or enable an integration. Establishing certain standards upfront, including our HTML-first approach, SOLID and DRY principles, and linting and formatting conventions (among others), helped prevent later rework. We deliberately postponed other decisions until a more concrete need emerged.
And to be clear, I’m not running mutation tests or elaborate security scans. It’s a static website without user accounts and with a limited attack surface. That would be overkill for my use case. A financial platform handling sensitive customer information warrants a different level of engineering rigor than a hobby website generating fantasy character names. The challenge is knowing how much rigor the work actually warrants.
The key is to be responsible by using what you need, not what is cool.
As development continued, I expanded the harness to do more than simply trust that the agent was doing what it said it was doing. We introduced automated validation for formatting, code duplication, unused code, and other quality concerns. All using free or open-source tools that don’t depend on generative AI.
Again, I didn’t automatically choose the most sophisticated option available. With the agent’s help, I evaluated what was worth introducing and what would create more burden than benefit. Some required experiments to determine whether they added value or introduced more rework than they were worth.
None of this is perfect. The agent can independently write code, run tests, identify certain defects, and correct its own mistakes. But I still need to recognize when something doesn’t make sense, question why it chose a particular approach, and verify that it’s following our established standards. Frankly, these are the same things I’ve had to do with human developers for years.
And that highlights something important: AI does not replace expertise.
I built my first website when I was 12 years old, and I’ve been building ever since. That experience helps me recognize what to ask for, when to challenge a recommendation, and when something isn’t behaving as intended. AI-assisted development allowed me to delegate the coding while focusing my attention on other parts of the product. It’s almost like a more dynamic no-code solution. WordPress 3000.
I need to be careful how I word this: 12-year-old me wasn’t an expert. That’s part of what made me fall in love with technology. I didn’t need a degree or anyone’s permission to get started. I could experiment, make mistakes, learn, and improve. AI makes that opportunity accessible to even more people, and I think that’s worth celebrating.
But there’s a danger in confusing the ability to produce something with the competence to evaluate it. There’s a psychological phenomenon called the Dunning–Kruger effect, where people lacking expertise in a particular area can also struggle to recognize the limits of their own abilities. Now combine that with AI producing convincing results that may or may not be correct and we risk becoming overconfident in both the technology and ourselves.
One area where that distinction becomes particularly apparent is design. I’ve found AI perfectly capable of producing generic, functional designs. What it struggles with is knowing when to lean in, when a little extra attention might make an experience memorable, or which of the countless possible approaches would best serve the product.
For example, I spent hours refining a single button on my website. I wanted it to resemble a cut ruby, shimmer subtly, and respond to interaction in a particular way. The agent repeatedly produced implementations that technically worked but didn’t create the experience I wanted.
I had to find examples, explain what I liked about them, challenge the results, and sometimes get creative with how I described my feedback. I couldn’t rely on the shared design context I might have with an experienced human developer.
And this isn’t limited to visual design. I still personally validate completed work, something I encourage every Product Manager to do today with human-powered teams. I’m also the only one who authorizes production releases, because I’m ultimately accountable.
Where I’m going with this is that AI changes how we work, but it doesn’t relieve us of deciding what to build, why it matters, or whom we’re serving.
Saying we need to use AI is like saying we need to use the internet. While it’s directionally true, it provides zero actual direction. I still need to decide what I want to accomplish, understand the people I’m trying to serve, and determine whether the result is valuable. AI has changed where I spend my attention, not my responsibility for the outcome.
I’m also not suggesting my approach is the best or only approach. A $400/month subscription might be an excellent investment for someone whose work genuinely benefits from that capability. An elaborate system of specialized agents might deliver substantial value in a sufficiently complex environment. But neither should become the default simply because the technology exists.
Lean isn’t a prescription to use the fewest tools, spend the least money, or eliminate every possible expense. It’s a way of thinking about how we create value while continuously improving the systems that produce it.
For this project, that meant starting with a Sheets prototype. Using conventional automation when conventional automation was sufficient. Validating quality before scaling. Applying engineering controls proportionate to risk. And retaining human judgment where it added value. It also meant recognizing that expertise in building solutions isn’t the same thing as understanding which solutions deserve to be built.
The goal shouldn’t be to maximize how much AI we use. It should be to maximize the value we create by using it.
The application and its MIT-licensed code are publicly available on GitHub. Feel free to explore the project: https://github.com/bradleynelson/elf-name-generator