DEV Community: Betty Wu

One Tap, Four Meanings: What a Thumbs-Down Actually Teaches

Betty Wu — Fri, 24 Jul 2026 04:00:00 +0000

Part 3 of a series on building Wardrobe AI. Part 1 set up the guiding principle; Part 2 walked the pipeline that decides which clothes the model sees and promised a deeper look at the one stage it waved past, the feedback signal. This is that look. All the code in this post is public, in github.com/JiamanBettyWu/mise; snippets link to their source.

I wanted it to know my taste

The recommender from Part 2 was good at variety and weather, but it didn't know me. It didn't know I reach for neutral colors, that I think most outfits are improved by exactly one interesting piece, or that I quietly hate a particular jacket I keep meaning to donate. I wanted the app to learn my aesthetic over time, to get more me the longer I used it.

There are really only two ways to get taste into the system. The first is to just tell it: type "I prefer neutral basics" into a settings box and have the model treat that as a rule. Easy, and I built it (more on why it's a special case below). The second is to have it learn from my reactions: let me thumb outfits up or down and infer my taste from the pattern. That second path is where
all the interesting problems live, because recording a thumbs-down is trivial and learning the right lesson from it is not.

Here's the trap. I thumb down today's outfit. What did I just say? Maybe the jacket is ugly. Maybe the jacket is fine but clashed with those pants. Maybe the whole thing was lovely and it's just freezing and I wanted something warmer. Maybe it was perfect for a coffee run but I have a meeting. One tap, at least four completely different meanings, and if the system guesses wrong it doesn't just
miss once. It bakes the wrong lesson into every future morning. This post is about making that one tap teach the right thing.

Three doors a preference can walk through

Taste enters this system through three distinct doors, and (this is the whole point of the post) they are deliberately not treated the same:

Explicit preferences I write ("prefer neutral colors"). A hard constraint, honored in every outfit, no exceptions.
Per-item feedback (thumbs on individual outfits). A soft, self-correcting nudge, expressed as the sampling-weight multiplier from Part 2.
Inferred preferences: patterns a weekly "reflection" job distills from my whole feedback history ("you seem to avoid layering in summer"). Also soft, but fundamentally riskier. The machinery of that weekly job is its own story (Part 5); what matters now is how its output is treated.

Doors 2 and 3 are both "learning from feedback," but they fail in opposite ways. Hold that thought; first, the math behind door 2.

The math: what a thumbs-down does to the odds

Recall from Part 2 that every item carries a feedback multiplier that tips its sampling odds up or down. Here's how that number is actually computed, and why the obvious version is a trap.

The naive version. Track likes and dislikes per item; the item's score is its like rate, ups / (ups + downs). Clean, but brittle. Thumb down a shirt exactly once and its score is 0/1 = 0: a single bad day damns it forever. Thumb one up once and it's 1/1 = 100%: a perfect item on one data point. With the handful of
verdicts you actually accumulate day to day, raw rates lurch around wildly.

The fix: smoothing. Instead of trusting the raw count, start every item from a neutral assumption and let evidence move it:

score = (ups + 1) / (ups + downs + 2)      # 0 verdicts -> 0.5 (neutral)

^{→ full context: backend/services/outfit_history.py}

Those +1 and +2 are the whole trick. With no data, the score is 1/2, a shrug, "no opinion yet." One thumbs-down takes a fresh item to 1/3 ≈ 0.33, not 0: disliked, but not condemned on a sample of one. As real verdicts pile up, those constants matter less and the score converges on the true rate. This is a Beta-Bernoulli estimate, the textbook way to estimate a yes/no rate (here, "will I like it?") when samples are scarce, with the +1/+2 acting as a prior belief of 50/50. The everyday version: a restaurant with one 1-star review isn't really a zero-star restaurant. You assume roughly average until enough reviews
prove otherwise.

Spreading the blame. A thumbs-down lands on an outfit, but
the multiplier lives on items. If I dislike a four-piece outfit, which piece was
the problem? Honest answer: I don't know, and neither does the system. So it
refuses to over-blame: one verdict distributes one unit of credit or blame across the items:

credit = 1.0 / len(item_ids)               # a 4-item outfit -> 0.25 each

A single tap is one vote, not four. It nudges everything in the outfit a little,
rather than slamming each piece as if it were individually condemned. Over many
outfits, the genuinely bad item shows up in more dislikes and accumulates the
blame; the innocent bystanders that happened to be in one bad outfit recover.

Bounding it. Finally, that smoothed score (between 0 and 1) is stretched onto
a deliberately narrow multiplier:

mult = FLOOR + (CEILING - FLOOR) * score   # [0,1] -> [0.6, 1.4]

^{→ full context: backend/services/outfit_history.py}

The ceiling (1.4) keeps a beloved item from dominating every outfit. The floor
(0.6) is the one I want to call out, because it's the exploration vs.
exploitation dial from Parts 1 and 2 made concrete. Exploitation says "show me
what I've liked." Exploration says "keep showing me other things anyway." That
floor of 0.6 means even an item I've thumbed down repeatedly never drops to zero
probability; it just gets quieter. The system never stops exploring, even on the
stuff it thinks I dislike, because "I disliked it once in July" is not proof I
should never see it in October. The feedback multiplier exploits; the floor
guarantees exploration; both are tunable constants.

Disambiguating the tap

The math above quietly assumes the dislike was about the items. But remember the
four meanings of a thumbs-down. So a dislike can optionally carry an
attribution: was it the items, the combination, the weather, or the
occasion? That tag changes who gets blamed.

Specific items: blame lands only on the pieces I named. High-confidence signal.
The combination: the items are individually fine; it was the pairing. The items are exonerated (zero blame in the multiplier), and instead that exact set goes on the deterministic block-list from Part 2's post-generation filter. (This is where that "known-bad combination" tag came from: I promised you in Part 2, and here it is.)
The weather / the occasion: not the outfit's fault at all. The items are exonerated; a weather complaint is dropped from learning entirely (it's feedback on the forecast, not the wardrobe).

Attribution is what stops a single grumpy "too cold today" from quietly
penalizing four perfectly good items for the rest of the year. It routes each
verdict to the part of the system that can actually act on it: items to the
multiplier, bad pairings to the block-list, weather to the bin.

Recent verdicts also go into the prompt as plain context: disliked outfits
as an "avoid recombining similar assemblies" list, liked ones explicitly captioned
style direction only, do not recreate these. That caption is deliberate. Recency
weighting just pushed those exact items down to keep things fresh, and I don't want
the model clawing them back by hunting near-duplicates of something I liked last
week.

The real lesson: a loop that self-corrects vs. a bias that doesn't

Now the payoff, and the reason doors 2 and 3 exist as separate doors.

The per-item feedback loop (door 2) is safe to be aggressive because it
self-corrects. Suppose it over-penalizes a shirt after one unlucky dislike. The
floor keeps the shirt in rotation; it resurfaces; if I like it next time, its
score climbs right back. Wrong guesses get pulled back toward the truth by the
next data point. It behaves like a thermostat: it can overshoot, but the
feedback that caused the overshoot is the same feedback that corrects it.

An inferred preference (door 3) is a different animal. When the weekly reflection
job writes "you avoid bright colors," that sentence goes into the prompt and
shapes every outfit from then on. If it's right, wonderful. If it's wrong
(maybe I downvoted three bright things for unrelated reasons), nothing in the loop
fixes it. A wrong inference is a systematic bias with no floor: it quietly tilts everything, and the only thing that ever corrects it is me noticing and deleting it.

That asymmetry dictates the design. Because a wrong inference can't self-correct,
it has to be legible and overridable: every inferred preference is short,
specific, cites the exact feedback that produced it, and shows up in an editable
list I can prune in one click. And because it's soft, a hard preference I wrote
myself always wins when the two conflict. The model is told to lean on learned preferences but never to sacrifice weather, coherence, or an explicit rule. So a wrong inference degrades gracefully: it nudges a few outfits until I catch it, rather than quietly overruling everything.

This is the same organizing principle from Part 1, one level deeper. Part 1 split
physics (hard) from preference (soft). Here, within the soft world, there's
a second split: a signal that self-corrects can be trusted to be assertive; a
signal that can't must be kept legible, weak, and easy to stop.

Where this goes next

Door 3, the weekly "reflection" job that reads my whole feedback history and
distills durable preferences, has been lurking in the background this whole post.
It turns out to be a small AI system in its own right, with a surprisingly fussy
set of rules to keep it from doing exactly the kind of unrecoverable damage I just
described. But it's also the second of two agentic pieces in this project, so
before I get to it I want to introduce the agentic system with a friendlier
example: a trip packing planner that can decide its own next move. That's Part 4.

Go deeper

Everything in this post is real, running code:

The whole multiplier, smoothing + blame-splitting + attribution routing, is one pure function: _feedback_multipliers in backend/services/outfit_history.py
The hard-vs-soft split in the prompt (user preferences as constraints, learned ones as nudges): backend/services/claude.py
The design doc where these rules were actually worked out, trade-offs and rejected alternatives included: docs/feedback-loop-design.md

The Same Outfit, Four Days Straight: Fixing What the Prompt Can't

Betty Wu — Tue, 14 Jul 2026 16:02:00 +0000

Part 2 of a series on building Wardrobe AI. Part 1 covered what the
app does and the principle behind it: stochastic weights for preferences,
deterministic logic for physics. This post is where that principle earns its
keep. The feedback math gets a breadth-level mention here and a full treatment
in Part 3. All the code in this post is public, in
github.com/JiamanBettyWu/mise; snippets link to their source.

The bug that started it: four days, one outfit

The first version of the recommender was about as simple as it sounds: pull all my available clothes from the database, hand the whole list to the model, ask for an outfit. It worked. It also recommended me the same outfit four days in a row.

That's a special kind of disappointing, because it's not wrong. The outfit was fine all four days. The trouble is that a stylist who suggests the identical thing every morning isn't really doing the job. The whole value, as I framed it in Part 1, is the warm start: a fresh push to react to. A stuck recommendation is a cold start wearing a trenchcoat.

Why did it happen? Large language models have a well-known tendency to anchor on whatever comes first in their input. My database returned items in a stable order, so the model kept seeing the same clothes at the top of the list and kept reaching for them. The fix people reach for first is "tell the model to be more varied," and I did eventually do a version of that, but prompting alone is a soft nudge against a strong bias. The bigger lever turned out to be upstream.

The key idea: the model never sees the whole closet

Here's the realization that reorganized the whole feature: the quality of a
recommendation is decided mostly before the AI is ever called.

Instead of dumping my entire wardrobe on the model, I built a pipeline that curates a smaller candidate pool first, a deliberately chosen, shuffled subset of clothes, and only that goes to the model. Think of the model as the host at a party greeting guests, and the pipeline as the bouncer with the guest list. By the time the host says hello, the bouncer has already decided who's in the room. Most of the interesting decisions live with the bouncer.

The pipeline is almost entirely deterministic plumbing wrapped around two
small bits of randomness. Here's the whole thing end to end:

Let me walk it stage by stage. I'll go deep on everything except the feedback math, which has enough subtlety to deserve its own post (Part 3); here it's just "a number that tips the odds."

Stage 1: The extremes gate (physics, and it runs first)

Before anything gets weighted or sampled, a deterministic filter drops items that are absurd for today's weather, like a heavy parka when it's 30°C (86°F). This is the "physics" side of the principle: there's nothing fuzzy about "it's too hot for a parka," so it's a hard rule, not a probability.

It runs first, and the ordering matters. If absurd items were still in the pool during sampling, they'd take up slots that should go to wearable clothes. A parka sitting in the candidate pool on a hot day is, at best, an item the model ignores and, at worst, one it accidentally picks. Gate first, then the model only ever reasons about clothes that make sense for today.

Note what the gate does not do: it only removes the absurd extremes, not the merely-suboptimal. Fine-grained "is this warm enough for a cool morning" judgment is handled later, by the model itself. That two-tier split (hard gate for the absurd, model judgment for the nuanced) comes back when we get to the prompt.

Stage 2: Recency decay (so yesterday's clothes step back)

This is the direct fix for the four-days bug. Every item gets a recency score: the more recently (and more often) it's been recommended, the higher its score, with the influence fading a little each day. Concretely it's exponential decay, where each day in the past counts for less:

DAILY_DECAY = 0.85           # per-day multiplier; ~4-day half-life
# an item worn d days ago contributes DAILY_DECAY ** d to its recency score

^{→ full context: backend/services/outfit_history.py}

"Half-life" here means that after about four days, a wear counts for half as much; after eight, a quarter. The analogy is a music shuffle that's smart about repeats: a song you just heard drops down the queue, but it doesn't fall off the playlist. Nothing is ever banned for being recent; it's just made less likely for a while, so the rotation breathes.

One subtlety I got wrong the first time and had to fix: recency pressure only makes sense when you have substitutes. I have exactly one pair of dressy shoes. Penalizing them for "you wore them yesterday" just means tomorrow's elevated outfit has no shoes at all. So items in a small category (at or below a threshold count of available pieces) are exempt from recency entirely. Rotation is for when there's something to rotate to. I learned this the way most of these rules got learned: it did something dumb first. (I call it the sandals incident, and it shows up again below.)

Stage 3: The feedback nudge (breadth only; full story in Part 3)

Alongside recency, each item carries a feedback multiplier derived from my thumbs-up / thumbs-down history: liked items get their odds gently boosted, disliked ones gently reduced. Crucially, it's a bounded nudge (it never drives an item's probability to zero or to certainty), which keeps a little exploration alive even for things I've thumbed down.

That's all you need for the pipeline view: it's a number that tips the dice. How that number is computed (it involves a smoothed Bayesian estimate and blame attribution) is the subject of Part 3.

Stage 4: Weighted sampling (where the randomness happens)

Now the two signals combine into a single sampling weight per item:

w = recency_factor * feedback_multiplier

Then I draw a random subset, roughly 70% of the pool, where an item's weight is its chance of being picked. Higher weight (not worn lately, generally liked) means more likely to make the cut; lower weight means less likely, never impossible.

The neat part is how you sample without replacement when every item has a different weight. There's an elegant one-liner for it (the Efraimidis–Spirakis algorithm): give each item a random key and sort by it.

key = math.log(random.random()) / w     # bigger weight -> key closer to 0 -> ranks higher
# sort all items by key (descending); the top k are a correct weighted sample of size k

^{→ full context: backend/services/outfit_history.py}

This uses only the standard library: no dependencies, no model call, fully deterministic to debug given a fixed random seed. This is the "stochastic" half of the system, and it's deliberately small and contained.

This is also where Part 1's exploration vs. exploitation trade-off stops being an abstraction and becomes literal code. The feedback multiplier is the exploitation lever: it leans on what's already worked, pulling proven items up. The randomness in the draw is the exploration lever: it keeps putting less-favored and not-recently-worn items in front of me, which is exactly how I stumble onto combinations I'd never have chosen myself. There's a subtler reason for exploration, too. The feedback multiplier can only learn about items it actually shows me; a piece that never gets sampled generates no verdicts. So rotation isn't only about variety, it's what feeds the taste-learning. Kill the randomness and you'd quietly starve the very thing that's supposed to get smarter over time.

The nice part is that the balance between the two isn't hard-coded into the logic; it lives in a handful of tunable constants: how hard a thumbs-up boosts an item, what fraction of the wardrobe gets sampled (~70%), how fast recency decays (DAILY_DECAY = 0.85). Nudge them one way and the app plays favorites; nudge them the other and it turns adventurous. How far to push each dial, and why the feedback nudge keeps a hard floor so it never stops exploring entirely, is a Part 3 question.

Stage 5: Category floors (don't evict all the shoes)

Random sampling has a failure mode: by chance, a draw can wipe out a whole category. Pull 70% at random and you might end up with zero shoes in the pool, and then there's no possible complete outfit, no matter how clever the model is.

So after sampling, category floors top the pool back up: guarantee a minimum number of tops, bottoms, shoes, and outerwear. If a category fell below its floor, the next-best items (the ones just outside the random cut) get promoted back in until the floor is met. It's cheap insurance (having an item in the pool costs nothing; the model can always ignore it), and it's the final piece of the sandals incident: not just "don't rotate away the only shoes," but "never let the dice remove an entire category."

Stage 6: The candidate pool meets the model

After the floors, what's left is the candidate pool, the curated, shuffled rack the model finally gets to see. Now the model gets called. One detail matters for what comes next: it doesn't return a single outfit per mode, it returns three candidates, ordered best-first. Hold onto that, because it's
what makes the last filter possible. First, how the prompt steers the call itself.

One line of logging makes the whole pipeline debuggable. Every run prints the pool it built, which answers the question I ask most often when an outfit surprises me: was that item sampled out, or did the model just ignore it?

INFO wardrobe.recommend: candidate pool (52 of 73 after gate + sampling): 
'90s Vintage Maxi Denim Skirt front slit, 
Aritzia Wilfred black suit vest, 
Black cushioned recovery flip flop,
Black long-sleeve merino crew tee,
Black ribbed boat-neck tee,
Blue satin strapless ruched tube top,
Cream collarless ultra light down jacket, ...

That's a real run: 73 items available, 21 gated or sampled out today, 52 in the room when the model starts picking.

The other half: steering the model with the prompt

Everything above curates which clothes the model considers. The system prompt handles how it assembles them. The two are complementary levers, and I tuned the prompt the same way I tuned the pipeline: by watching it fail and writing a rule.

Three passes are worth sharing.

Warmth, the nuanced tier. Remember the extremes gate only removes the absurd. Everyday "is this actually warm enough for a 9°C (48°F) morning" is a judgment call, so I gave it to the model: every item has a warmth rating from 1 to 5, and the prompt asks it to reason about the outfit's combined, layered warmth against today's high and low (light pieces for heat; for cold, either a high-warmth piece or several lighter layers). Hard gate for the absurd, model judgment for the nuance: the same physics-versus-context split.

Omit a slot rather than force a bad one. My favorite failure. The model kept pairing sports sandals with an elegant dress, repeatedly. The logic was understandable: an outfit needs shoes, and after sampling the sandals were sometimes the only footwear left, so it dutifully jammed them in. The fix was to make "complete" optional:

An outfit missing shoes beats an outfit with off-mode shoes.

The prompt now tells the model that if nothing fits a slot for the occasion, it should leave that slot empty and note the gap in its reasoning, rather than forcing something off-key. It's a small example of treating the prompt as policy: an incomplete-but-coherent outfit is more useful than a complete-but-absurd one.

Explore the full set. Finally, the prompt closes the loop on the original bug. It tells the model explicitly that the inventory order is randomized and implies no preference, so explore the whole set rather than defaulting to the first few items. On its own this would be a weak nudge against the anchoring bias. But it's not on its own: the sampler already shuffles the pool every time, so the prompt and the pipeline push the same direction from two sides. The randomized order removes the stable thing the model was anchoring to; the instruction tells it not to anchor on whatever it gets handed instead.

An honest epilogue to the four-days bug, though: these two forces killed the worst of the repetition, but months later I caught a sneakier version of the same disease. The model had developed a fondness for alternating between two similar favorites. The fix was a third force: the prompt now also receives a short list of what it recommended in the past week, with an instruction to prefer pieces that aren't on it. How I found that pattern, proved the fix actually worked with numbers instead of vibes, and then verified it in production is a story about building an eval loop, and it gets its own post later in the series.

Stage 7: The post-generation filter (known-bad and exact repeats)

This is the one stage that runs after the model, on its output rather than its input, which is exactly why the model returns three candidates instead of one. A final deterministic filter walks the candidates and takes the first one that survives two hard checks:

Known-bad combinations. If I've thumbed down an outfit and flagged that the problem was the combination specifically (not the weather, not the occasion), that exact set of items is rejected permanently. This isn't a soft preference to whisper to the model; it's a recorded fact, so it's enforced in code. (Where that "it was the combination" tag comes from is a Part 3 story.)
Exact recent repeats. Any exact outfit recommended in the last 7 days is also rejected, so the same assembly can't reappear within the week. This is set-level dedup; item-level rotation is recency's job back in Stage 2.

Now the three-candidates choice pays off: if the best candidate is rejected, the filter falls through to the next acceptable one instead of coming back empty-handed, and only if every candidate is a known-bad combo does it skip the mode. The prompt asks for variety; this filter enforces it.

Stepping back

The shape of this whole feature is the Part 1 principle made concrete. The parts that should be reliable (don't suggest a parka in July, never empty a category, never repeat a known-bad combo) are deterministic code I can step through and debug. The parts that should be lively are a small, bounded dose of randomness. The model sits at the end, doing the hard part of assembling a coherent outfit, but only over a set the pipeline has already made safe and varied.

The one stage I kept waving past, that feedback multiplier, turns out to be the most subtle of all. Recording a thumbs-down is easy; learning from it correctly is surprisingly hard, and getting it wrong quietly poisons everything downstream.

That's Part 3.

Go deeper

Everything in this post is real, running code:

The sampler (recency decay, weighted sampling, category floors): backend/services/outfit_history.py
The extremes gate: backend/services/weather_gate.py
The system prompt with the warmth, slot-omission, and explore rules: backend/services/claude.py
The full algorithm reference, with formulas and worked examples: docs/recommendation-algorithm.md

I Outsourced Getting Dressed to an AI (and Accidentally Built Three of Them)

Betty Wu — Fri, 10 Jul 2026 21:17:52 +0000

This is Part 1 of a series on building Wardrobe AI, a personal app that
recommends what to wear. This post is the map: what it does and how it's put together. Later posts go deep on the recommendation math, the feedback loop, and the two agents running underneath. Code samples are kept light here; the details get their own posts.

Everything in this series is a running app with public code and history:
github.com/JiamanBettyWu/mise (the repo is named mise, as in mise en place, but I'll call it Wardrobe AI
throughout). Later posts link the specific files and pull requests as they come up.

It started in front of my closet

A few months ago I was standing in front of my closet before work, running late, staring at a rack that was visibly full of clothes, and thinking: "I have nothing to wear."

Which was obviously false. I had plenty to wear. That was the actual problem — the rack was overwhelming. Too many options, no obvious answer. What I was experiencing wasn't a shortage of clothes. It was decision fatigue, the small daily tax of having to assemble a reasonable outfit from scratch every single morning before my brain is fully online.

So I had a second thought, the one that actually mattered: I should just outsource this decision.

That's the entire origin of the project. Not "wouldn't it be cool to use AI for fashion," but something more like "I have a recurring, low-stakes decision I'd happily hand to a machine, and I have enough context (my actual clothes, the weather, my calendar) to make a decent suggestion possible."

What it actually does

The app is a personal wardrobe catalog with an AI stylist bolted on. The setup cost is one-time: I photograph each piece of clothing, and a vision model tags it automatically with type, color, formality, season, fabric, even a rough warmth rating. I review the tags, fix anything it got wrong, optionally add a note, and save. After that, the catalog just exists.

From there, the day-to-day value shows up in two channels.

A push channel: the morning email. Every morning I get an email with an
outfit suggestion (sometimes a few, depending on what my calendar looks like that day), chosen for the actual weather and reasoned out in a sentence or two. I don't have to open anything; it just arrives.

A pull channel: on-demand generation in the app. The email is great for the default "what do I wear to the office today" case, but some days are not the default when I have a special event. So the app's Today's Outfit page has a notes box ("Describe theoccasion, then click Generate") where I can ask for something specific: dinner out, an interview, cold rain, a day on my feet. It generates suggestions for that context, and if the first batch doesn't land, I hit Regenerate.

There are two more capabilities I'll only mention here and unpack later: a trip packing planner (give it a destination and dates, get a weather-appropriate packing list, and if you're missing something for the trip it'll even find things to buy), and a style learner that quietly studies which suggestions I liked and distills durable preferences over time.

What success actually looks like: a warm start, not a verdict

It's worth being clear up front about what this app is for, because it's easy to assume the goal is an AI that dictates your outfit while you obey. That's not it. It isn't meant to replace my judgment or have the final say on what I wear. It's meant to do two narrower, more useful things.

First, it gives me a warm start. Cold start is the "I have nothing to wear" paralysis — a blank slate and no idea where to begin. A warm start is being handed a plausible draft to react to. It's the difference between a writer facing an empty page and a writer editing a rough draft, and the second is so much easier. That alone removes most of the daily decision fatigue,
which was the whole point.

Second, it nudges me toward outfits I wouldn't have assembled on my own. Left to myself I reach for the same handful of safe combinations; a system with a little randomness in it occasionally pairs things I'd never have tried, and sometimes that's the best part. This is the classic exploration vs. exploitation trade-off, balancing the reliable favorite against the worthwhile gamble, and it's a big enough idea that it gets real treatment in Part 2.

Both goals share a freeing consequence: the app doesn't have to be right, only useful. That tolerance is what lets me lean on randomness and learning instead of chasing an impossible standard of correctness.

The twist: this isn't one AI, it's three

When I started, I assumed "the AI" would be a single thing: feed it my clothes and the weather, get back an outfit. What I ended up with is three different AI systems, because the three jobs turned out to have different shapes.

The daily recommender. The thing behind the morning email and the on-demand button. It's actually the least fancy of the three under the hood: plain, straight-line Python that prepares the right inputs and makes one call to the model. No agent framework, no graph. (Most of its cleverness is in how it chooses which clothes to even show the model, which is Part 2.)
The trip planner. Packing is a bigger problem than "what do I wear today," because it can spawn follow-up work: if you're missing something the trip needs, the system should go find it. That "do a step, then maybe do a different step depending on what you found" shape is what people mean by an agent: a program that decides its own next move at runtime. I built this one on LangGraph, a library for wiring those steps into a graph. (Part 4.)
The style learner. Once a week, in the background, a second LangGraph reads my whole history of thumbs-up/thumbs-down feedback and tries to distill it into durable preferences ("leans toward neutral basics," that sort of thing). Same tool as the trip planner, completely different job, and, it turns out, completely different risks.(Part 5.)

If you only remember one thing from this post, make it this: the three systems share a single design principle, and that principle is the spine of everything that follows.

The one principle: stochastic for preferences, deterministic for physics

Early on I kept running into the same fork in the road: should this piece of behavior be a hard rule, or a soft nudge? After enough of those decisions I noticed I was answering them all the same way, and the rule generalized:

Use stochastic weights for preferences, and deterministic logic for physics.

Let me unpack the two words. Stochastic just means "involving randomness": behavior that's probabilistic rather than fixed. Deterministic means the opposite, the same input giving the same output every time, no dice rolls.

The insight is that the app's inputs split cleanly into two kinds:

Preferences are soft, fuzzy, and accumulate over time. "She probably doesn't love this shirt." Getting one of these wrong on any given day is harmless; remember, it's a warm start. So preferences belong in the stochastic parts of the system: things like randomized, weighted sampling, where the wrongness washes out over time and a little randomness is actually a feature (it's what keeps suggestions varied).
Physics are hard constraints about the real world. "It is 4°C andraining." There's nothing fuzzy about that. Recommending shorts isn't a charming bit of variety; it's just broken. So physics belongs in the deterministic parts: explicit filters and gates that run the same way every time and that I can debug when they misfire.

The reason this matters, and the reason I made it the organizing principle, is that mixing the two up creates the worst kind of bug. Encode a hard physical constraint as a soft probabilistic nudge and you get failures that are unreproducible: it recommends a parka on a hot day one time in twenty and you can never quite catch it. Encode a soft preference as a rigid rule and the app becomes brittle and samey, suggesting the same "safe" outfit forever. Keeping the two in separate homes is what keeps the system both lively and trustworthy.

You'll see this principle cash out concretely in every remaining post: in how the recommender randomizes which clothes it considers but hard-filters weather-absurd ones (Part 2), in why thumbs-feedback adjusts probabilities rather than banning items outright (Part 3), and in how the two agents separate "decide what to do" from "do it reliably" (Parts 4 and 5).

A note on the stack (because cheap was a constraint)

This is a personal app for exactly one user (me), and I wanted it to cost roughly nothing to run. That shaped a lot of pragmatic choices worth a quick mention: a Python/FastAPI backend, a React frontend, Supabase for the database and photo storage, and Anthropic's Claude models for the AI parts. The one choice I'm quietly proud of is the morning email: instead of paying for a hosted scheduler, the daily job runs on a free GitHub Actions cron, the same automation most people only use for running tests. All in, the whole thing costs me somewhere around one to two dollars a month, almost entirely model usage. That number comes from a dashboard, not a guess: the app meters its own model calls in a small ledger table and shows me the running cost. The constraint of "free" turned out to be a good forcing function for simple architecture.

Where this series is going

That's the map. Five core posts, each opening on the actual moment or annoyance that drove the work, then the engineering decision it led to:

This post: the overview and the physics-vs-preference principle.
The recommendation engine: how it avoids suggesting the same outfit four days in a row (a thing it absolutely did, at first) without ever putting me in a parka in July.
Closing the feedback loop: why a thumbs-down is trivial to record and surprisingly hard to learn from correctly.
Going agentic with LangGraph: the trip planner, and what "agent" actually buys you over a plain function.
LangGraph again, for learning: the weekly style learner, the same tool doing the opposite job, and why a system that quietly changes its own behavior needs very different guardrails.

And it won't stop at five: the app is alive, so the series will follow it. Whenever a new piece of the system is worth writing about, it becomes a Part 6, a Part 7, and so on. (The next candidate is already queued: how I built an eval loop to measure whether the recommender was actually getting better, instead of just feeling like it was.)

Want to poke around?

The code is public at github.com/JiamanBettyWu/mise. If you enjoy seeing how a project actually gets built (as opposed to how it looks once it's tidied up for a blog post), the repo carries two artifacts I kept while building: a session-by-session journal of what shipped and why (SESSIONS.md, and an unpolished, chronological log of every gotcha that bit me (LEARNINGS.md. Between them, they're the honest version of this series. Each later post links the specific files and pull requests it describes.

If the idea of handing a small daily decision to a slightly-unreliable machine sounds interesting, the next post is where it gets concrete. See you there.