DEV Community: Dermin

Pixel Chef AI: A Memory Kitchen That Learns Your Taste

Dermin — Sun, 02 Aug 2026 03:12:58 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

🍳 Pixel Chef AI — A Memory Kitchen That Learns Your Taste

What I Built

Pixel Chef AI is an interactive AI cooking companion built around a simple idea:

Food is not only about recipes. It is about memories, habits, emotions, and personal taste.

Instead of being a traditional recipe generator, Pixel Chef AI creates a complete AI-powered cooking journey:

🧊 Enter the Memory Kitchen

🥬 Choose ingredients

🤖 Let AI analyze flavors and nutrition

🔥 Cook with real-time AI guidance

🍽️ Reveal your final dish

🧬 Build your personal Taste DNA

Every cooking session becomes a memory.

Over time, the AI learns your cooking preferences, flavor choices, and habits to create a more personalized kitchen experience.

The core question behind this project:

What if your AI assistant could remember how you cook and become your personal kitchen companion?

✨ Features

🧠 AI Taste Intelligence

Pixel Chef AI is designed around the idea that cooking decisions are personal.

The AI analyzes:

Ingredient combinations
Flavor balance
Nutrition information
User preferences

It can:

Predict flavor direction
Suggest ingredient improvements
Recommend better combinations
Adapt suggestions based on cooking goals

🤖 AI Cooking Companion

A pixel AI chef accompanies users throughout the entire cooking process.

The AI provides:

Ingredient analysis
Flavor recommendations
Cooking suggestions
Real-time guidance during cooking
Personalized feedback

The goal is to make AI feel like a kitchen partner, not just a chatbot.

🧊 Interactive Pixel Kitchen

The experience starts inside a cozy pixel-art kitchen.

Users can:

Open the fridge
Select ingredients
Create their own combinations
Watch AI analyze their choices

The kitchen becomes a place where users interact with AI through cooking.

🔥 AI Cooking Simulation

Cooking becomes an interactive experience instead of a simple result page.

During cooking:

A cooking timeline controls progress
Different cooking events appear
AI provides suggestions
Users can make decisions

The AI chef stays involved throughout the process.

🍽️ AI Dish Reveal

At the end of each cooking session, AI creates a complete cooking memory:

Final dish showcase
Cooking score
Flavor analysis
AI chef story
Personal memory record

Each dish becomes part of your cooking journey.

🧬 Taste DNA Memory System

Every cooking experience helps build a personal taste profile.

The AI analyzes:

Ingredient preferences
Flavor choices
Cooking style
Nutrition habits

Then creates a unique cooking personality:

🔥 Fire Chef

🌿 Healthy Creator

✨ Flavor Explorer

🍖 Comfort Cook

Your kitchen becomes smarter over time.

🚀 Demo

Experience the complete AI cooking journey:

https://pixel-chef-ai.vercel.app/

Source Code:

https://github.com/vivayang911/pixel-chef-ai

Try the flow:
Memory Kitchen

↓

Ingredient Selection

↓

AI Flavor Analysis

↓

Cooking Guidance

↓

Dish Creation

↓

Taste Memory

🌱 Journey

I started this project with a simple question:

What if AI could become a personal cooking companion instead of just a recipe generator?

Many AI food tools focus on creating recipes.

I wanted to explore a different direction:

An AI system that understands people, remembers habits, and helps make everyday food decisions.

The biggest challenge was not creating a cooking interface.

The challenge was:

How can AI feel present throughout the entire experience?

Instead of a single AI response, Pixel Chef AI creates a continuous relationship:
User Choice

↓

AI Understanding

↓

Cooking Assistance

↓

Personalized Result

↓

Memory Creation

Through this project, I explored how AI can evolve from a simple assistant into a personal lifestyle companion.

🏠 Future Vision — AI as the Brain of a Smart Kitchen

Pixel Chef AI is designed as a concept for the future of intelligent kitchens.

The next evolution could connect AI with real-world devices:

🧊 Smart refrigerators

📷 Ingredient recognition cameras

🛒 Grocery platforms

💪 Nutrition and fitness systems

By connecting with IoT devices, AI could understand:

What ingredients are available at home
Personal taste preferences
Health goals
Dietary restrictions
Family eating habits
Seasonal and regional preferences

The AI could then help manage daily food decisions:

Recommend meals based on personal goals
Adjust recipes during fitness or weight-loss periods
Create family meal plans
Generate shopping lists
Connect with grocery services

The future vision is not simply:

"What should I cook today?"

but:

"How can AI help me build a healthier and happier life through food?"

🛠️ Technical Highlights

Built as a pure frontend AI experience.

Tech Stack

React 18
TypeScript
Vite
Tailwind CSS
Framer Motion

Architecture

Pixel Chef AI uses a client-side AI decision engine:
User Interaction

↓

AI Chef Engine

↓

Flavor Analysis

↓

Cooking Decision System

↓

Taste Memory Engine

The entire experience runs directly in the browser.

No backend or database is required.

🔮 Future Improvements

Possible future directions:

Real AI model integration
Smart refrigerator connection
Computer vision ingredient recognition
Real nutrition analysis
Grocery ordering automation
Personal health management

Built With

Created for:

DEV Frontend Challenge — Comfort Food Edition

Thanks to the DEV community for encouraging creative frontend experiments.

License

MIT

Building Q-EOS: When Control Theory Meets Multi-Agent AI Governance

Dermin — Wed, 24 Jun 2026 07:44:52 +0000

Building Q-EOS: When Control Theory Meets Multi-Agent AI Governance

How I built a six-agent token economy governance system grounded in academic research — and what I learned about why architecture matters more than algorithms.

The Problem I Wanted to Solve

Token economies are fragile. When a stablecoin loses its peg, the typical response is a static rule: "if price drops below X, buy Y tokens." But static rules are pro-cyclical — they buy aggressively when the treasury is already stressed, and they ignore the difference between a temporary dip and a structural collapse.

I wanted to build something smarter. Not just "LLM makes decisions" — but a system where multiple specialized agents collaborate, check each other, and maintain safety guarantees even when individual components fail.

Starting with Theory, Not Code

Most hackathon projects start with a cool idea and work backwards. I started with a paper.

The Dynamic Control Buyback Mechanism (DCBM), published in arXiv:2601.09961, identifies static rule-based buybacks as a root cause of pro-cyclical volatility in token economies. The paper proposes a PID controller as the core stabilizer:

$$u(t) = K_p e(t) + K_i \int e(t)dt + K_d \frac{de(t)}{dt}$$

Where $e(t) = P_{target} - P_{current}$ is the price deviation from peg.

This gave me a concrete theoretical anchor. Q-EOS isn't a demo of API calling — it's an implementation of a formal framework, extended with multi-agent governance and LLM-powered decision transparency.

The Architecture: Six Agents, One Pipeline

The core insight was separation of concerns. Each agent does exactly one thing:

Observer → Risk → PID → Policy → Governor (Qwen-Plus) → Treasury

Observer: fetches real-time market price
Risk: scores threat level (price deviation triggers risk_score=80 when price < 0.97)
PID: computes optimal intervention using Kp=3000, Ki=50, Kd=500
Policy: dynamically adjusts intervention strength (multiplier 0.5–1.5 based on deviation, risk, and treasury health)
Governor: Qwen-Plus makes the final APPROVE/REJECT decision with written rationale
Treasury: executes approved actions, enforces four hard constraints

All agents communicate through a Message Bus — no agent calls another directly. This made testing and debugging dramatically easier.

The Three-Layer Safety Architecture

One design principle I kept coming back to: in financial governance, "doing nothing" is far better than "doing the wrong thing."

This shaped the safety architecture:

Layer 1: PID Control     — computes ideal action
Layer 2: Qwen Governance — approves or rejects with reasoning  
Layer 3: Treasury        — enforces hard limits regardless of Qwen

The Treasury layer runs independent of Qwen. Even if Qwen approves an action, Treasury will block it if:

Single transaction exceeds 10% of treasury balance
Price is in extreme range (< 0.7 or > 1.3)
Treasury balance falls below 5,000 USDC
Recent net consumption exceeds 5% of treasury

This is the fail-closed principle: when uncertain, reject and hold. Never default to approving.

What Broke (And How I Fixed It)

JSON Parsing Hell

Qwen-Plus doesn't always return clean JSON. Sometimes it wraps the response in Markdown code fences:

json
{"decision": "APPROVE", "reason": "..."}

Direct json.loads(text) throws an exception. I built a three-layer parser:

Try direct parse
Strip Markdown fences, try again
Regex extract the first {...} block

The Silent Policy Layer Bug

Early in development, pid.py was sending messages directly to "Governor", bypassing Policy entirely. The Policy agent was running — but receiving zero messages, doing nothing. The six-agent pipeline was secretly a five-agent pipeline.

The fix was one line: change "Governor" to "Policy" in the message destination. But finding it required carefully tracing every message through the bus.

The USE_QWEN=False Trap

I added a fast mode (USE_QWEN=False) for development — it skips real API calls and uses local if-else rules. I accidentally left it on for one batch of runs, producing data that showed 0% rejection rate and a treasury that inexplicably grew to $55k. The numbers looked great. They were completely fake.

Lesson: always verify which mode you're actually running in before trusting simulation data.

The Baseline Experiment That Surprised Me

To validate multi-agent advantage, I ran three configurations over 30 identical market days:

Metric	Single Agent	Single + PID	Q-EOS Multi-Agent
Final Treasury (USDC)	45,588 (-4,412)	50,000 (+0)	53,351 (+3,351)
Execution Rate	100%	0%	100%
Max Drawdown	12.2%	0%	1.8%

The Single+PID result was the most revealing. I gave it the exact same PID algorithm as Q-EOS — same Kp, Ki, Kd — but with a single Qwen instance handling all roles. It rejected every single proposal for 30 consecutive days.

Why? A single Qwen instance reviewing its own proposals has no separation between perception (Observer), risk scoring (Risk), and execution enforcement (Treasury). With no independent checks, it consistently judged interventions as too risky to approve.

Multi-agent architecture wasn't just better — it was the only thing that worked.

What Qwen-Plus Actually Does

Every governance decision includes a written rationale. Here's a real example from Day 340 of the 365-day simulation:

"Treasury balance (49,272.05) is sufficient to absorb the intervention of 59.045 without compromising liquidity or solvency; risk score of 80 is elevated but within acceptable operational thresholds for this asset class and intervention context; price of 0.9693 shows mild deviation but no evidence of extreme volatility or flash crash conditions — no abnormal market conditions detected."

This is what transparency looks like in practice. Every rejection is traceable. Every approval has justification. Nothing is a black box.

Deployment on Alibaba Cloud

Q-EOS runs on Alibaba Cloud ECS, calling Qwen-Plus via the DashScope API. The complete stack:

Compute: Alibaba Cloud ECS (Ubuntu 20.04)
LLM: Qwen-Plus via DashScope API
Framework: Python + custom Message Bus
Control: PID controller (from arXiv:2601.08399)
Safety: Three-layer hard constraint system

What I Learned

1. Theory first, code second. Starting from a published paper gave Q-EOS a coherence that most projects lack. I could always answer "why did you design it this way?" with a citation.

2. Fail-closed is a principle, not a feature. When the API is unreachable, when JSON is malformed, when the agent pipeline has a bug — the system should reject and hold. Not approve by default. This applies to any system handling real resources.

3. Multi-agent separation of concerns is a governance principle, not just an engineering pattern. A single agent cannot reliably serve as its own auditor. Specialization enables both decisiveness and safety simultaneously — something a single-agent system fundamentally cannot achieve.

4. Measure everything. The baseline comparison was the most convincing part of the submission. Without it, Q-EOS is just "a multi-agent system that seems to work." With it, it's a system with a 7x reduction in max drawdown and a measurable architectural advantage.

DEV Community: Dermin

Pixel Chef AI: A Memory Kitchen That Learns Your Taste

🍳 Pixel Chef AI — A Memory Kitchen That Learns Your Taste

What I Built

✨ Features

🧠 AI Taste Intelligence

🤖 AI Cooking Companion

🧊 Interactive Pixel Kitchen

🔥 AI Cooking Simulation

🍽️ AI Dish Reveal

🧬 Taste DNA Memory System

🚀 Demo

🌱 Journey

🏠 Future Vision — AI as the Brain of a Smart Kitchen

🛠️ Technical Highlights

Tech Stack

Architecture

🔮 Future Improvements

Built With

License

Building Q-EOS: When Control Theory Meets Multi-Agent AI Governance

Building Q-EOS: When Control Theory Meets Multi-Agent AI Governance

The Problem I Wanted to Solve

Starting with Theory, Not Code

The Architecture: Six Agents, One Pipeline

The Three-Layer Safety Architecture

What Broke (And How I Fixed It)

JSON Parsing Hell

The Silent Policy Layer Bug

The USE_QWEN=False Trap

The Baseline Experiment That Surprised Me

What Qwen-Plus Actually Does

Deployment on Alibaba Cloud

What I Learned

Links