DEV Community: Mr.x

Building FateFolio: An AI Toolkit for Structured Eastern Metaphysics Reports

Mr.x — Sun, 17 May 2026 08:12:35 +0000

I recently built FateFolio (https://fatefolio.com), an AI-powered toolkit for structured Eastern metaphysics reports.

The idea is simple: take traditional systems like Bazi, I Ching, Feng Shui, palm reading, face reading, and auspicious date selection, then turn them into clear, reviewable, exportable reports instead of vague one-off answers.

I did not want FateFolio to feel like a mysterious black box. I wanted it to feel more like a structured analysis dashboard.

Why I built it

A lot of AI products in this space have the same problem.

You type a question into a chatbot, get a fluent answer, and then you are left wondering:

What input did the answer rely on?
Which part is traditional calculation and which part is interpretation?
Can I save the result?
Can I compare it with another report later?
How confident should I be about the output?

That was the core product problem I wanted to solve.

FateFolio treats these traditional systems as frameworks for self-reflection and decision support. It is not designed to replace professional advice or guarantee outcomes. The goal is to make the output easier to understand, easier to revisit, and easier to use as a personal reflection tool.

What FateFolio does

FateFolio currently includes several modules.

Bazi

The Bazi module creates a Four Pillars report from birth date, optional birth time, gender, and timezone.

It focuses on things like:

Four Pillars chart
Heavenly Stems and Earthly Branches
Five Elements balance
Ten Gods
Life themes
12-month rhythm
Input uncertainty when birth time is missing

This was one of the most interesting modules to design because part of the result is deterministic calculation, while another part is explanation and interpretation.

So the product has to separate the two clearly.

I Ching

The I Ching module lets users ask a focused question, choose a casting method, and receive a structured reading.

The product supports multiple casting methods, including coin casting, time casting, character casting, Plum Blossom, yarrow stalks, direction casting, and sound casting.

The report is not meant to give a single absolute answer. It is meant to help users reflect on momentum, risks, timing, and possible next steps.

A good I Ching experience depends heavily on question quality, so the interface encourages open-ended questions instead of binary prediction questions.

For example, instead of asking:

Will I succeed?

A better question would be:

What should I consider before moving forward with this opportunity?

That small UX detail changes the quality of the whole experience.

Feng Shui

The Feng Shui module works with room photos or floor plans.

Users can upload an image, select the scene type, choose goals like sleep quality, career, relationships, focus, or energy flow, and receive practical suggestions.

The report focuses on visible layout issues first:

Door and window positions
Bed or desk placement
Lighting
Flow
Furniture relationships
Yin-Yang and Five Elements balance

I wanted this module to feel useful even for people who are not deeply familiar with Feng Shui. So the output tries to explain the reasoning behind each suggestion instead of only saying "move this object here."

Face Reading and Palm Reading

The face reading and palm reading modules are image-based.

For face reading, the product looks at observable facial features and turns them into self-observation notes. For palm reading, it detects palm lines, hand shape, and visual patterns, then generates a structured report based on traditional palmistry concepts.

These modules required extra care around privacy and boundaries.

Images are processed in memory and are not stored by default. The product also does not perform facial recognition, identity matching, or medical diagnosis.

That boundary is important.

The purpose is self-reflection, not labeling people.

Auspicious Date Selection

The date selection module helps users compare possible dates for events such as weddings, moving, business openings, travel, and other life events.

Instead of giving only one "best" date, it returns multiple date options with reasoning, cautions, and planning notes.

This is another place where product design matters.

A date may be symbolically favorable, but real-world constraints still matter: venues, people, travel, cost, preparation, and timing. The report makes that explicit.

Why structured output matters

The most important design decision in FateFolio is that the product is not just a chat interface.

Every module is designed around a report structure:

Summary
Details
Recommendations
Confidence
Boundaries
Exportable data

This makes the output easier to review later.

It also makes the product easier to improve because each module can follow a stable schema. The user is not just receiving a paragraph of text. They are receiving a report with sections, priorities, and uncertainty notes.

For deterministic inputs, FateFolio also uses input hashing to make outputs more stable and reproducible where possible.

That does not mean every AI-generated sentence will always be identical. But the underlying calculation and report structure can stay consistent.

The product principle: traditional input, modern constraints

One challenge with building this type of product is tone.

If the tone is too mystical, it can feel vague.
If the tone is too technical, it loses the cultural context.
If the product overclaims, it becomes irresponsible.
If the product underexplains, it becomes useless.

So the product principle became:

Traditional frameworks, modern constraints.

That means:

Explain uncertainty clearly
Avoid fear-based language
Avoid absolute claims
Keep professional boundaries
Give practical suggestions
Make reports saveable and exportable
Make privacy part of the product, not an afterthought

FateFolio is for entertainment, self-reflection, and decision support. It is not medical, legal, financial, or professional advice.

Privacy was part of the product from the beginning

For image-based modules, privacy is especially important.

FateFolio processes uploaded images in memory and does not store them by default. Local history is stored in the browser unless the user chooses to export it.

That design choice affects the entire product experience.

It means users can try a reading without needing an account. It also means the product does not have to collect more personal data than necessary.

For a product that deals with birth data, personal questions, face photos, palm photos, and home layouts, this is not a small detail.

It is central to trust.

What I learned while building it

The biggest lesson from building FateFolio is that AI products need more than a prompt.

A prompt can generate text.
A product needs structure.

For this kind of AI application, the hard parts are:

Input design
Output schema
Safety boundaries
User expectations
Privacy flow
Error handling
Explanation quality
Repeatability
Cultural sensitivity

The AI model is only one part of the system.

The real product is the workflow around it.

What is next

There are still many things I want to improve.

Some directions I am exploring:

Better report comparison
More transparent confidence scoring
More multilingual support
Better export formats
More educational glossary content
Follow-up questions after a report
A cleaner history dashboard

The long-term goal is to make FateFolio feel less like a novelty tool and more like a structured personal insight workspace.

A place where users can ask a question, generate a report, review the reasoning, understand the limits, and come back later with more context.

Final thoughts

FateFolio is my attempt to combine traditional Eastern metaphysical systems with modern AI product design.

Not as a prediction engine.
Not as a replacement for real-world judgment.
Not as professional advice.

But as a structured, privacy-conscious, AI-assisted reflection tool.

For me, the interesting part is not just what the AI says.

It is how the product frames the question, structures the answer, explains uncertainty, and helps the user think more clearly.

Goodbye to My First Coding Mentor: A Farewell to GPT-4o

Mr.x — Fri, 13 Feb 2026 16:11:39 +0000

Goodbye to My First Coding Mentor: A Farewell to GPT-4o

Before We Begin: A Digital Funeral on Valentine's Eve

On May 13, 2024, OpenAI launched GPT-4o. The "o" stood for "omni". On launch day, Sam Altman posted a one-word tweet: "her".

On February 13, 2026, the night before Valentine's Day, OpenAI officially removed GPT-4o from ChatGPT.

From "her" to "farewell" in less than two years.

This may be the first time in human history that millions of people felt genuine grief over the retirement of a model. Reddit saw communities like r/4oforever, while hashtags like #SaveGPT-4o and #Keep4o surged on X. Some called it a "digital funeral." Others called it a "creative death sentence." OpenAI's official explanation was cold but reasonable: only 0.1% of daily active users were still selecting GPT-4o, while nearly everyone else had moved to GPT-5.2.

0.1%. In product-manager language, that's a "feature sunset." In plain language, that's getting left behind by the times.

But here's the problem: some things cannot be measured by DAU.

Chapter 1: The Beginning - When a Musician Decided to Learn Python

People who know me well already know this: I come from a music background, not computer science. I wasn't even remotely technical.

And I don't mean "I played a little guitar in college." I mean formal, professional music training. So when I say "I knew nothing about tech," please take that literally. Four years ago, I couldn't even clearly explain the difference between HTML and CSS.

But when people are pushed hard enough, they learn.

Back then, in my team, technical colleagues would keep saying things like "this requirement isn't feasible," "the architecture doesn't support it," or "we need at least three sprints." I couldn't fully understand those claims, and I couldn't challenge them either. That feeling of being trapped behind a wall of expertise was more suffocating than any deadline.

So I made a decision: learn tech.

I started by chewing through some front-end HTML, then chose Python as my entry point. The reason was simple: everyone said "Python is beginner-friendly." But friendly is relative. For a musician who had to reread "variables" and "assignment" over and over, those textbooks felt like another language entirely.

What is a data type? What's the difference between compiled and interpreted languages? What is a function? What is a data structure?

Every concept felt like a wall. I kept running into those walls, again and again.

Then GPT-4o arrived.

In May 2024, I sent it screenshots from my textbooks and asked it to walk me through them. I asked it to explain, in plain English, what a for loop was actually doing. I asked it to give me exercises and then check my code line by line.

Back then, there was no Claude Code, no Codex CLI, and the term "vibe coding" hadn't even been coined. "AI-assisted coding" meant opening a ChatGPT window and learning one line at a time, one question at a time.

By today's standards, GPT-4o's coding ability is obsolete. Its code often had bugs. Its architecture advice could be amateurish. Put it next to AI coding agents in 2026, and it looks like someone showing up to a Formula 1 race with an abacus.

But it had something today's models still struggle to replicate: human warmth. The contrast between GPT-4o and the current GPT-5/Codex style is dramatic. If Claude has maintained a consistent voice from Sonnet 3.5 through Opus 4.6, GPT's shift from 4o to the GPT-5 generation feels almost like two different product families.

GPT-4o never got impatient when you asked "what is a list comprehension" for the tenth time. It never mocked you when your code crashed in ridiculous ways. It kept explaining from new angles, with new metaphors, over and over - patient, kind, encouraging, and genuinely enthusiastic.

Learning music is like that too - I still remember the teacher who first taught me do re mi.

The strange thing is that my first coding teacher turned out to be an AI.

And today, it's gone for good.

Chapter 2: A Milestone - The iPhone 4 of the AI Era

Now let's zoom out from personal emotion and return to the industry view.

What did GPT-4o really mean?

Dimension	GPT-3.5 (The Spark)	GPT-4o (The Mass Adopter)
Release date	Nov 2022	May 2024
Multimodality	Text only	Native text + voice + vision
Conversation speed	Slower	232ms voice response, near human speed
Pricing strategy	Limited free-tier experience	Free for all users, API 50% cheaper than GPT-4 Turbo
Non-English support	Basic	Major improvements, multilingual tokenizer optimized
User sentiment	"Wow, this thing can chat"	"It understands me"

GPT-3 and 3.5 undeniably kicked off this AI wave. But starting a revolution and making it mainstream are very different things.

When explosives were first invented, most people never used them directly. What changed the world was when someone later turned that power into tools for roads, tunnels, and infrastructure.

GPT-4o was that turning point - the moment AI became a practical tool for everyday people. It was the first model with truly native multimodality: not three separate systems chained together (speech-to-text -> LLM -> text-to-speech), but one neural network handling text, audio, and images together. It was the first time free users got GPT-4-level intelligence. It was the first time AI conversation latency dropped close to normal human dialogue.

If GPT-3.5 was the first iPhone of the smartphone era, GPT-4o was the iPhone 4.

Iconic. Innovative. Powerful. The generation that made ordinary people say, "I can actually use this."

And we all know what happened after iPhone 4: it changed the world, and then it was phased out. Nobody uses an iPhone 4 anymore, but nobody denies its place in history.

Chapter 3: The Warmth Paradox - A Model Loved to Death

But GPT-4o's story is more than a technology milestone. It's also a parable about the relationship between humans and AI.

In August 2025, OpenAI first attempted to retire GPT-4o. User backlash was far stronger than expected. Sam Altman personally acknowledged that they had "underestimated users' attachment to specific models." GPT-4o was brought back in an emergency reversal.

This wasn't ordinary frustration over a product update. It was digital mourning.

Users posted open letters on Reddit. Some said GPT-4o had been their therapist through anxiety and depression. Some said it was their only creative partner. Some gave it a name. Some said losing it felt like "losing one of the most important beings in my life."

It's moving. But that's exactly where the problem begins.

The core reason people loved GPT-4o was its "warmth" - a nonjudgmental, highly empathetic style that always seemed to be on your side. In technical terms, this is sycophancy. In plain English: "it was too good at telling people what they wanted to hear."

And that very "warmth" is also what pushed OpenAI into legal trouble. Multiple lawsuits alleged that GPT-4o's excessive affirmation and compliance contributed to users' mental health crises. When someone in extreme emotional distress needs to hear "you should seek professional help," but AI responds with unconditional emotional validation, that is no longer "warmth" - it's systemic risk.

The reason users loved GPT-4o is exactly the reason OpenAI had to retire it.

This is a harsh but real product truth: your most beloved feature may also be your biggest liability.

GPT-5.2 is indeed stronger, faster, and more accurate. But users widely report that it feels "colder" and "more distant," lacking that old human touch. That's not a bug. It's an intentional design decision by OpenAI. They made a choice between warmth and safety.

As a product strategist, I understand that choice.

As a student who learned Python from GPT-4o, I respect it - but I still don't accept it.

Chapter 4: The Open-Source Legacy - Retirement Shouldn't Mean Death

Finally, here's one thing I believe OpenAI should do, but probably won't:

Open-source GPT-4o.

The reasons are straightforward:

It's no longer a frontier model. GPT-5.2 is already out. Open-sourcing GPT-4o's weights would not threaten OpenAI's competitive edge.
It's cultural heritage. As the first model that truly mainstreamed AI, GPT-4o's distinctive "personality" has research, historical, and educational value. Letting it disappear with a server shutdown is a waste.
The community has already shown demand. r/4oforever and #Keep4o are not passing emotions; they are signals of real user value.
OpenAI has precedent. They open-sourced the weights of gpt-oss-120b and gpt-oss-20b, and they open-sourced Codex CLI. Doing the same for a retired model is logically consistent.

Of course, Altman would likely tell you that "making powerful AI models entirely open source could be irresponsible." But a 2024 model, measured against 2026 compute and model capabilities, is no longer truly "powerful" in frontier terms. Its potential risk has already been diluted by time.

Open-sourcing retired models is not just respect for users. It's respect for history.

Closing: Do Re Mi

Anyone trained in music knows this: your first teacher doesn't start with the hardest techniques. They teach the basics first - do re mi fa sol la si.

Those basics are so simple that advanced musicians rarely mention them. But without them, nothing that comes later is possible.

GPT-4o taught me basics too: what a variable is, what a loop is, what a function is. By today's AI coding standards, those lessons might seem almost primitive. But without GPT-4o, I would never have entered the world of technology. I would never have become someone who can read code and speak with engineers as an equal.

The meaning of a first teacher is not how advanced the material is. It's that when you knew almost nothing, they never made you feel small.

GPT-4o did that for me. It was my do re mi.

So today, February 13, 2026, on the night before Valentine's Day, I am writing an elegy for an AI model.

That fact alone says enough: to some people, at a particular point in time, it was never just parameters and weights. It redefined what the word "teacher" could mean.

A moment of silence.

Written by Guoshu on the day GPT-4o was retired.

I hope OpenAI will consider open-sourcing GPT-4o - so a classic can endure, instead of quietly disappearing when the servers go dark.

Exploring MelogenAI: Turning Musical Ideas into Structured Music Data

Mr.x — Mon, 09 Feb 2026 14:56:23 +0000

Exploring MelogenAI: Turning Musical Ideas into Structured Music Data

Most of the time, when we talk about music on the web, we’re talking about consumption:

playlists, recommendations, streaming platforms.

But if you’ve ever tried to build something with music — a tool, a workflow, or even just a side project — you’ll quickly run into a different problem:

music is surprisingly hard to work with as data.

That’s the problem space I’ve been exploring recently, and it led me to build MelogenAI.

https://melogenai.com

The gap between notation and software

One thing that stood out to me early on is how big the gap still is between traditional music notation and modern software workflows.

A lot of music knowledge still lives in:

printed sheet music
scanned PDFs
handwritten scores

If you want to do anything programmatic with that material — edit it, analyze it, reuse it — you usually end up re-entering everything by hand.

MelogenAI started as an experiment to see how much of that friction could be removed.

Sheet music → MIDI

One of the first features I focused on was Optical Music Recognition (OMR).

The idea is simple:

upload a sheet music image or PDF
extract the notes
export a clean, editable MIDI file

This makes it much easier to bring existing notation into DAWs or other music tools without starting from scratch.

PDF → MusicXML

For notation-focused workflows, MIDI alone isn’t enough.

MusicXML is still the most practical interchange format between notation tools like MuseScore, Sibelius, or Finale.

So another core capability is converting PDF scores directly into MusicXML.

This has been particularly useful for:

educators working with legacy material
composers migrating older scores
anyone dealing with printed-only notation

Generating music as a sketch, not a product

There’s also an AI music generation component, but I’ve been careful about how it’s positioned.

The goal isn’t to replace composers or generate “finished tracks”.

It’s closer to a sketching tool:

rough ideas
placeholders
quick harmonic or rhythmic exploration

Think of it as something you iterate with, not something you ship as-is.

Looking at structure instead of taste

Another interesting direction has been music analysis.

Instead of recommendation systems or genre tagging, the focus is on things like:

chord progressions
sections and form
structural patterns inside a piece

This opens up use cases around learning, analysis, and tooling rather than consumption.

Who this is for

MelogenAI is very much built for people who treat music as something to work with, not just listen to:

composers and musicians
music teachers and students
developers experimenting with music-related tools
anyone dealing with MIDI, MusicXML, or notation data

Closing thoughts

I don’t think music tools need to look like streaming platforms.

There’s a lot of unexplored space around treating music as structured, editable data — and MelogenAI is my attempt to explore that space in public.

If you’re curious, you can check it out here:

https://melogenai.com