Delicio — AI meal-planning showcase.

Pulling a week of meals together usually means juggling pantry inventory, dietary preferences, what is in season, and how much time you actually have to cook on a given night. The interesting part — what to eat — gets buried under the logistics.

Delicio started from the question: what if an AI-assisted app handled the logistics so a household could focus on the choices that matter to them?

A household tells Delicio who is eating, what they have on hand, what they want to avoid, and how much time they have. Delicio drafts a week of meals, a single consolidated grocery list, and a short prep schedule that fits the available evenings.

The goal is not to replace the cook — it is to remove the dozen tiny decisions between idea and dinner.

Delicio shares the same stack pattern as the rest of the Thalos surfaces: a Next.js App Router frontend talking to a Django + Postgres backend through typed API routes. The LLM layer is wrapped behind a small interface so we can swap models without reshaping the app.

Recipe data, household profiles, and meal-plan history live in Postgres. The agent-facing scaffolding (prompts, evaluators, schema validators) lives in a shared package so the same patterns are reusable across Thalos projects.

Most of Delicio was implemented through agent-driven coding cycles: a small specification ticket, an agent run that produced a focused diff, a TDD pass to lock the behavior in, and a human review before commit. The discipline that made this work was the same one Thalos enforces elsewhere — every change tied to a ticket, every commit referenced back to that ticket, every test added alongside the feature.

The honest version: the agent-assisted parts moved fast when the surface was well-bounded (forms, list views, schema migrations) and slower when the work involved tasting decisions about UX copy or the meal-planning prompt itself, which still benefited from hand-tuning.

Thalos held the ticket backlog, the epic structure, the lessons-learned log, and the deploy pipeline. Every commit landed with a ticket trailer so the work history is reconstructable from the repo alone — useful for the writeup, and more useful when something needs to be audited later.

Thalos also hosted the agent-review feed that surfaced visual previews and intermediate states during the build so the operator did not have to wait for a finished page to give feedback.

Pail provided the day-to-day developer utilities the build leaned on: scratch buffers for in-flight thinking, share-cards for review surfaces, comparison views for before/after diffs, and the inbox that kept agent-to-operator handoffs from getting lost in chat.

It is also the tool attendees use during workshops to build their own prototypes — Delicio is a useful proof that the same surface holds up for real product work, not just classroom demos.

The hardest parts were not the engineering. Getting the meal-planning prompt to produce plans a real household would actually cook — and not just plausible-sounding meals — took several iterations of evaluators and human tasting. Prompt drift between model versions surfaced often enough that we ended up pinning model versions per environment.

The recipe corpus also has a long tail: every household has at least a few dishes that are not in any public dataset, and the experience falls flat the moment Delicio cannot speak to them. That part is still in flight.

Near-term: harden the meal-plan generator against the long-tail problem, finish the consolidated grocery-list export, and ship a public demo behind the same hosting that runs the rest of the Thalos surfaces.

After that: a household-recipe import path, a shopping integration for the grocery list, and a stronger evaluation harness so the meal-plan quality can be tracked over time instead of relying on operator taste.