标签：#dataset

Last month I wrote about building a 1,800-page calculator site solo. Since then the recipe hub on that site grew to 501 dishes from 127 countries — and today I'm releasing all of it as an open dataset. Download JSON (full dataset, ~2.6 MB): https://theunitools.com/data/unitools-recipes-v1.json CSV (one dish per row): https://theunitools.com/data/unitools-recipes-v1.csv Docs + sample record : https://github.com/farcrak/unitools-recipes Dataset page: https://theunitools.com/en/data What's inside 501 home-cooking recipes, 127 countries, bilingual (English + Russian, both written by hand — no machine translation) Per-serving nutrition (calories, protein, fat, carbs) on every single dish 3,200+ steps, each annotated with minutes Ingredients with stable ids and scaling rules : meat scales linearly with servings, salt and spices are damped — the way an actual kitchen scales a recipe, not naive multiplication Human-reviewed Wikimedia Commons photos with author + licence per photo Why the scaling rules matter Most recipe datasets store "2 tbsp salt for 4 servings" and leave scaling to you. Multiply salt linearly to 16 servings and the dish is inedible. Each ingredient in this dataset carries a scaling field ( linear | damped | fixed ), so a portion calculator can be built directly on top of the data. That's exactly how the recipe pages on the site work. Licence CC BY-SA 4.0 — free for commercial use. Credit "UniTools — theunitools.com" and share derivatives under the same licence. Photos carry their own Commons licences (in the data). Honest caveats Nutrition is computed from ingredients, not lab-measured — a planning reference, not medical data. The dataset is maintained by one person; if you spot an error, open an issue on the repo and the fix lands in the next version. If you build something with it — a meal planner, a viz, a model fine-tune — I'd genuinely love to hear about it in the comments.

Gone are the hours of careful thought and planning that go into coding a new feature. Vibe coding is too risky though, so another Driven Development was created. I'm referring to SDD (Spec Driven Development) of course. The vibe coding approach is great for prototypes and throwaway code, but this way of working falls apart when teams realise that the code needs to be maintained. So the thing that helps fix this is SDD. Create a spec once from clear technical specs and then generate some high quality code. Sounds great, right. Reminds me of IaC, where you use a templating language to create infrastructure. Software as Code maybe. SaC anyone? Unfortunately, in practice it's not that straightforward. Thoughtworks have placed SDD into an "Assess" category and warned that it could be an anti-pattern for releasing software. Deterministic vs Probabilistic This article isn't about SDD. I'm more interested in discussing the output of SDD and how that is tested. Code can now be generated fast these days. So what better to test AI-written code than with AI itself. There are a lot of concepts and technical terms for the Quality Assurance part of AI generated code. One of these is the LLM-as-a-Judge idea. This idea is used to score the output of an LLM based on some explicit criteria. Traditionally, the way to evaluate an LLM was to judge its output on the helpfulness or faithfulness (using something called "exact-match" metrics). Sometimes it was usually down to a human to do this. It also changes the way that Quality is Assured when dealing with AI-written code. Traditional QA is built on deterministic checks; either something does or does not fail. Something like expect(x).toContainText(y); . A failing test means that something is wrong. Then the bug can be fixed in the code and the test will pass. However, the outputs of an LLM are probabilistic , so it breaks the traditional pass/fail model. This is where a judge comes in. Instead of pass/fail, it can assign a score based o