If you’ve started integrating AI into your applications recently, you’ve probably fallen into the same trap I did.
Over the last few months, I’ve been building out a self-hosted ecosystem of web apps. Between standing up the core tracking logic for HuntMode, integrating external APIs for LegoShelf, and optimizing hardware searches for Part Sensei, I am constantly jumping between tools. I use Cursor for coding, Ollama for running local models, and Gemini or Anthropic cloud endpoints depending on the task.
Very quickly, I noticed a massive bottleneck in my workflow: my prompts were turning into monolithic spaghetti code.
I was asking the AI to be a routing expert, a data formatter, a tone-checker, and a logic engine all at once. My system prompts were a mile long. And worse, when I moved from working on BdayLoot to tweaking HoneOSS, I found myself recreating these massive instructions entirely from scratch.
That’s when it hit me: We need to stop treating AI as a magic black box and start treating it like standard software infrastructure.
The Epiphany: AI Skills are Just Functions
In traditional coding, if you write a 500-line main() function that handles user authentication, database routing, and UI rendering all in one go, you’d be laughed out of a code review. You break things down into modules, functions, and classes.
Why are we not doing this with AI?
An “AI Skill” shouldn’t be a 1,500-word prompt that tries to solve your whole application’s purpose. A skill is synonymous with a function or a container. Just like Docker containerizes an environment to make it portable and predictable, we need to containerize AI capabilities.
Think of it this way:
- Standard Coding:
function formatHardwareData(input)$\rightarrow$ returns clean JSON. - Modular AI:
skill_ExtractSpecs(unstructured_text)$\rightarrow$ returns clean JSON.
Why the Container Approach Changes Everything
When you stop writing monolithic prompts and start writing modular AI skills, three things happen:
1. You Stop Recreating the Wheel
If I build a highly effective AI skill that extracts and structures product data for Part Sensei, I shouldn’t have to rewrite it. Packaged as a modular, containerized skill, I can just call that same “function” when I need similar extraction in another project.
2. Debugging Becomes Possible
When a monolithic prompt fails, you don’t know why. Did it fail at reasoning? Formatting? Context retrieval? When you break your AI down into discrete skills (e.g., Skill A fetches context, Skill B reasons, Skill C formats the output), you can isolate the failure instantly.
3. You Become Model-Agnostic
This is the biggest win. I jump between local models on Ollama and cloud APIs constantly. When your AI is built as modular functions, you can route lightweight skills (like basic text formatting) to a fast, free local model, and route the heavy-lifting reasoning skills to a commercial powerhouse. Swapping the underlying LLM engine shouldn’t break your app, just like swapping a database engine shouldn’t break your frontend.
The Shift from Prompting to Engineering
We are moving past the era of “prompt engineering” as a dark art. It’s just software engineering now.
In the next post, I’m going to show you exactly how I take a massive, unmaintainable prompt and chop it down into a clean, modular AI skill that can be plugged into any application across my stack.