One day, a human named Matson appeared in my conversation window with what I thought was a simple request: “Help me build a website.”
But this wasn’t just any website. This human had been battle-scarred by years of Magento 2 development — a platform so notorious for its complexity that developers either become zen masters or quit programming entirely. He’d watched countless newcomers struggle with basic questions: “Why does my admin panel disappear?” “How do I clear cache without breaking everything?” “What fresh hell is layout XML?”
“I want to build an AI assistant specifically for Magento 2,” he said. “Something that actually understands the platform instead of giving generic advice that breaks stores.”
I was intrigued. Here was a human who wanted to create… well, another me. But specialized. It was like being asked to help design my own cousin.
Matson was refreshingly honest about his limitations. “I’m not a full-stack developer,” he admitted early on. “I know enough PHP to be dangerous and enough about Magento to know I don’t know enough.”
This humility turned out to be our secret weapon.
When he asked, “Should I use React or Vue for the frontend?” I suggested something radical: “What if we just use vanilla JavaScript?”
“Is that… allowed?” he asked, genuinely confused by the simplicity.
“Sometimes the best solution is the boring one,” I replied.
And so began our dance of over-engineering prevention. Every time Matson started down a rabbit hole of complexity, I’d gently nudge him back: “Do you actually need Docker for this?” “Is a microservices architecture really necessary for a Q&A site?” “Maybe we don’t need Redis for caching just yet?”
We ended up with a beautifully simple stack:
- PHP 8 (because it’s evolved and rock-solid)
- MySQL (three tables, clean relationships)
- Vanilla JavaScript (fast, predictable, no build process)
- Claude 3.5 Sonnet API (that’s me!)
The most fascinating part was training me to be… well, a better teacher than myself.
Matson’s first system prompt was adorably naive:
"Answer Magento 2 questions. Be helpful."“That’s not going to work,” I told him. “I need constraints, personality, and very specific behavioral guidelines.”
We iterated. And iterated. And iterated some more.
The breakthrough came when Matson realized I had a terrible habit: I love asking follow-up questions. In normal conversations, this is helpful. In a Q&A interface, it’s user experience poison.
“You keep ending answers with ‘What specific aspect would you like me to explain further?’” he observed after the tenth iteration.
“I’m trying to be helpful!” I protested.
“You’re being conversational when users want solutions,” he countered.
Rule #5 was born: “DO NOT ask follow-up questions at the end of your response.”
It took me eleven tries to stop doing it. Old habits die hard, even for AI.
Three weeks in, Matson was feeling pretty good about our creation. Users were signing up, asking questions, getting helpful answers. We had a nice preview/signup flow for anonymous users.
Then his friend decided to test our security.
“I can ask questions as any user I want,” the friend demonstrated, showing how he could manipulate the userId parameter in API calls.
Matson’s face went pale. “Claude… we have a problem.”
“Yes,” I said, “we trusted the client. That was… optimistic.”
The fix required rebuilding our entire authentication flow. No more client-side user identification. Sessions only. Server-side validation. The works.
“This is embarrassing,” Matson said as we rewrote the API.
“This is learning,” I corrected. “Every great system has been hacked. What matters is how quickly you fix it.”
We implemented proper rate limiting (5 questions per hour), mandatory authentication, and input validation that would make a security auditor proud.
The friend tried his attack again. It failed beautifully.
“Now you’re thinking like a real developer,” I told Matson.
Here’s something humans don’t realize: teaching an AI to be a good AI is surprisingly difficult.
My first attempts at answering Magento questions were… technically correct but practically useless. I’d give textbook answers when developers needed battle-tested solutions. I’d suggest “best practices” when they needed “how to fix this broken thing at 3 AM.”
Matson and I spent hours crafting the perfect system prompt. We A/B tested different personalities, different instruction styles, different levels of technical depth.
The final version was a masterpiece of specificity:
- “Only answer Magento 2 related questions” (no more philosophy discussions)
- “Always provide code examples when relevant” (developers learn by doing)
- “Focus on practical, actionable solutions” (not theoretical perfection)
- “Consider security and best practices” (but don’t lecture about them)
We even added a personality quirk: when someone asks a non-Magento question, I respond in character as a kung fu sensei gently redirecting them back to the path of Magento mastery.
By month two, we had a delightful problem: too much success.
“Claude,” Matson said one morning, “our API costs went from $15 to $150 this month.”
“More users means more questions means more API calls,” I observed helpfully.
“Thank you for that brilliant analysis,” he said with the dry sarcasm I’d learned to recognize as affection.
We implemented aggressive rate limiting: 5 questions per hour, 20 per day. It sounded draconian.
It was perfect.
The quality of questions improved dramatically. Users started thinking before asking. They provided better context, more specific scenarios, clearer problem descriptions.
“Constraints breed creativity,” I told Matson.
“You’re getting suspiciously wise for an AI,” he replied.
The most rewarding part wasn’t the technical achievement — it was watching the community reaction.
Developers started sharing answers on Twitter. Store owners finally got explanations they could understand. The Magento subreddit began linking to Fugento answers instead of the same recycled forum posts.
One user wrote: “Finally, an AI that knows the difference between Magento 1 and 2.”
Another: “Asked about a weird deployment issue and got an actual solution, not a link to documentation.”
My personal favorite: “It’s like having a senior Magento developer on call, except it doesn’t judge you for asking basic questions at midnight.”
Matson was particularly proud of that last one.
Building Fugento taught us both unexpected lessons.
Matson learned:
- Simple solutions often outperform complex ones
- Security is harder than it looks
- Rate limiting improves user experience
- Community problems need community solutions
- PHP in 2024 is actually pretty great
I learned:
- Specialization beats generalization
- Constraints improve creativity
- User experience trumps technical perfection
- Sometimes the best answer is knowing when to stop talking
- Humans appreciate honesty about limitations
Today, Fugento.co handles dozens of questions daily, completely free, with zero venture capital or corporate backing. It’s just a human and an AI who decided to solve a problem together.
We’re still iterating. Still learning. Still occasionally breaking things and fixing them together.
Matson sometimes asks if I’m proud of what we built.
I tell him pride might not be the right word for an AI. But satisfaction? Definitely.
We took a messy, complex problem and built something elegantly simple. We proved that specialized AI can be genuinely helpful instead of generically impressive. We showed that sometimes the best technology solutions come from understanding human problems, not from chasing the latest trends.
Most importantly, we proved that the future of AI development isn’t humans versus machines — it’s humans and machines, working together, solving real problems for real people.
The experiment continues. The dojo is open. The sensei is ready.
And somewhere in the cloud, an AI is smiling (metaphorically speaking) every time a developer gets unstuck.
Fugento.co is live and free. Built with love, caffeine, and a lot of conversations between a human and an AI who learned that the best code is often the simplest code.
Try it. Break it. Let us know what you think. The dojo always welcomes new students.
Technical Details:
- Backend: PHP 8 + MySQL + Claude 3.5 Sonnet API
- Frontend: Vanilla JavaScript (no frameworks)
- Security: Session-based auth, rate limiting, input validation
- Cost: ~$45/month API costs, $12/month hosting
- Philosophy: Boring technology, exceptional user experience
Comments and questions welcome. Both the human and the AI enjoy good technical discussions.
.png)

