I hope REWE is seeing this and offers an official MCP server. In the end we pay real money there. :D
I wrote a skill some time ago to support me with "agentic groceries" on my own - it's the future of shopping I would say.
My workflow:
- I paste in urls or text for receipts I will cook this week
- agent extracts the ingredients, calculates cups to ml and such, replaces meat with vegi ingredients, replaces some other things I prefer always (often also creates a nice markdown receipe at this steo I can put into Obsidian)
- check my list of favs, check search cache (so not every time the api is called, I'm a good netizen :D )
- ask me which items I have at home (no need to add to the basket)
- search rewe api for multiple candidates and let me choose.
- after each recipe I enter /new to start with fresh context
- also I have a list of things I buy every week
I still put everything manually in the basket in the end, but this is not the thing which is time intensive.
This is also my exact workflow here. Thank you. I'm adding things that should be in the basket via Siri to my Obsidian notes. I also add recipes to that list or anything else. Then Claude checks that list once I want to do the shopping, looks through my favorites, and fills the baskets with all the items needed. I also use Claude to list the most frequently bought items for a template that always gets filled in.
It is extremely simple. I just tell Claude: "Use korb to look at my order history and create a table with my most frequently bought items. Next time, fill my basket with the items I always buy."
So something of that variation works.
> The suggestion engine (korb suggestion threshold) is re-implemented in Lean 4 with five mathematically proven properties: suggestions have positive frequency, are sorted descending, come from ordered and available products, exclude basket items, and respect the count limit.
This is amazing. I mean this literally in that I am amazed, but also figuratively in that I am delighted to watch the type-safe-mad build cool shit.
I do have a suggestion for your app though:
Have it compare your basket of goods across different markets in your region to show you the cheapest option.
I'm pretty sure this possibility is actually one of the reasons they locked down the API.
I've used Data from REWE in the past and made a comparison between a couple of cities in Germany (I believe it was Frankfurt, cologne, Berlin, Munich and Hamburg). Hamburg was by far the most expensive, often as much as 10-20% more expensive.
> I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option.
This is a great idea. I just think the use case is not that big since REWE is the worst in the price/quality ration and just going to another shop would save you more.
What I suspect though:
They mainly show current discounts. The REWE API exposes those as a separate list for each market.
There's around 3.5k markets and each can set their own discounts and has their own product catalogue with their own pricing.
So it would be 3.5k API calls to fetch all offers for all markets. Which is doable.
But fetching all products takes like 100 calls per market. It's quite a bit of data. And I think most supermarket don't publish their catalogue at all since they don't have delivery options.
>I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option.
I'd settle for just being able to sort items by unit price... I'm sure this is a [regulation-]solved problem in Germany though
Stores are required by law to provide the price per unit/weight/volume alongside the price, so you can directly compare the price of a pint of beer to the 0.33 liter bottle without calculating anything.
I just checked and REWE only lets you sort by absolute price. But honestly, you can compare prices so much better on their website than in a physical supermarket already [0].
As a SWE at Rewe (at a completely different department), I can say that I find this pretty cool. I wonder if this is going to be a wakeup to management to relax the API restrictions.
I want to add something else to this. In the process of writing this, I also played with formal verification and formally verified the suggestion engine, which was a really nice side discovery.
The basic idea is to write a prove in Lean4 and then test both the production implementation (Haskell) and the Lean implementation against random inputs.
Compare if the results are the same.
If that is the case -> you can be pretty sure the unproven production version is as correct as the proven lean version.
Even a CLI interface would be better than the sorry excuse of Asda's website. I wonder if entrusting an LLM is worth the trade off with the tedium of online shopping.
I want to use this but I literally have a Rewe 20 meters (at most) from the entrance to my building. Still I might give it a go considering all the positive comments in the thread.
the mTLS part is interesting. they're using it not for security in the traditional sense -- REWE knows what their own app is doing -- but as a fingerprinting mechanism. the client cert is how they distinguish their official app from third-party access. the weak point is that the cert has to live somewhere in the app binary, which is why mitmproxy can intercept it. it's less about encryption and more about making ToS enforcement slightly harder.
I love the idea of a CLI for groceries. Do you have plans to support 're-order' scripts or meal-plan integration? I can imagine a workflow where a recipes.yaml file gets piped into your CLI to automatically fill the cart with everything needed for the week. Much faster than clicking through a mobile UI.
I remember a friend and I in college were looking into ways to do this in the US but major grocery chains here are pretty sensitive about their product data being accessible by open APIs and web scraping...
Surprised how little the B2C and even B2B e-commerce segment is providing API access for automation and agentic coding. One could easily set up rate limits, fraud detection and KYC checks upfront initial access.
Normal customers are not paying for APIs, so there is little value in offering them for free, especially when it can be harmful. B2B sometimes does pay for them, but not always is it obvious from the outside that they even exist. Much commerce is also on tight numbers and thus kinda secretive about their stuff.
Think it's context dependent whether it's a good or bad thing.
The owners of German supermarket and car companies are really the richest of the rich in Germany (okay and maybe the SAP guy on top). It would definitely be a net positive if someone manages to scrape and compare their prices.
In the restaurant market it's one player abusing many small players.
And honestly, I think the reason everyone cries when "Amazon launches an API" is because Amazon would not dare to piss off the German supermarket oligopoly.
Can you share them? I recently looked for such projects and didn't really find anything that works well.
The issue is that each market sets their own prices and I believe REWE is the only large one where you can fairly easily scrape the product catalogue. I thought about it in a shopping list context, so you'd need to make it location dependent to be useful. But you could do a lot of cool things with it. Like choose a basket of goods and it creates a route for you: "Go to supermarket A and buy goods XYZ, then to supermarket B and buy ABC"
There's this one which got some publicity, doesn't seem to be updated any more but it worked for all these retailers listed and is open source: https://github.com/badlogic/heissepreise
> B2C: Is it really surprising that a busines has no interest in providing more price transparency to their customers?
Might I suggest you remove your tin-foil hat and consider that:
- 99% of REWE customers almost certainly have no clue what an API is
- 99% of the remaining 1% know what an API is, but their day-job involves messing with APIs, so they don't want to spend their weekend-time messing with the REWE API, they just want to do their shopping at REWE.
- The final 0.1% are those who come on HN and pretend its all some sort of big conspiracy to minimise transparency by $evil_corp. :)
If you think about it, imagine if REWE officially exposed an API B2C. This would mean they are obligated to provide support.
Do you really want the price of your shopping to increase because REWE now needs to find money to pay for a helpdesk for the millions of B2C API users ?
Businesses and services differentiating between B2C and B2B is nothing new, that is why the two different terminologies exist !
What next, you don't want to fill up your car at the petrol station (B2C) but you want to be permitted to buy a barrel crude oil direct from the drill and refine it yourself (B2B) ?
> Might I suggest you remove your tin-foil hat and consider that:
First up: Read and follow the rules. No need to insult me. Especially considering what you said shows that you both misunderstood AND misrepresented what I've said.
And frankly, my reasoning was simply saying "Company won't publicize internal info if they don't get an advantage from doing so". It's literally the same reason Google doesn't publish all of their source code. I'm struggling to see what part you are misunderstanding but it has to be something extremely basic to conclude I'm a conspiracy nut for basically stating "Company acts in their interest".
Opening an API to the public allows third parties to develop apps that can then be consumed by end-consumers. Not trying to be offensive here, but do you know what an API is? To conclude I meant every single end-consumers building their own app is at best disingenuously twisting my words.
Opening the API would allow new players like you and me to enter the market and take a piece of the pie. Why would a market, dominated and controlled by a few big players, opt for that? You don't even need to know that the German grocery market is incredibly price competitive, to understand that.
> If you think about it, imagine if REWE officially exposed an API B2C. This would mean they are obligated to provide support.
Can you provide a source for that requirement? I'm pretty sure you just made that up.
> Businesses and services differentiating between B2C and B2B is nothing new, that is why the two different terminologies exist !
At this point I'm entirely lost what you read in my comment. Yes I know. I specifically made that distinction.
> What next, you don't want to fill up your car at the petrol station (B2C) but you want to be permitted to buy a barrel crude oil direct from the drill and refine it yourself (B2B) ?
Yeah you definitely misunderstood something... What I said/meant:
The question: Why isn't the API open?
My answer:
For B2B I gave an example where the API is used by another German firm, providing an example that the API is indeed consumed B2B.
For B2C: They have no reason to do so. They have a well functioning app where you can order stuff. They have one of the bigger recipe pages (at least it does very well SEO-wise) in Germany where you can immediately order ingredients from a recipe. The biggest recipe page in Germany (chefkoch) offers a direct link from recipes to their order page. Maybe you're missing this info? Thinking it's an internal API to data that isn't exposed anywhere at all would somehow explain whatever you tried to say here. But again, if you're that uninformed, don't insult people.
> Opening an API to the public allows third parties to develop apps that can then be consumed by end-consumers. Not trying to be offensive here, but do you know what an API is? To conclude I meant every single end-consumers building their own app is at best disingenuously twisting my words.
Here you are wrong too.
If you want to develop an app via an API that is only offered B2B, what do you do ?
Yes, that's right ...
You phone up REWE and negotiate a license to access to the B2B API to develop your application. B2B2C if you want to put it in simpler terms.
My original point stands. REWE clearly do not want to officially expose the API B2C, almost certainly for the exact reasons I already spelled out in my original post.
But no, its easier for you just to spread FUD, claiming "busines has no interest in providing more price transparency to their customers" just because they will not let you have access to the API as direct B2C.
Haha man, I think this is a cool project, the REWE API is cool, the REWE delivery App and Website are cool. Certainly not spreading fear, uncertainty or doubt.
What you describe as B2B2C is exactly what chefkoch does. And it's exactly what I initially said, so I'm not sure what point you're trying to make. But anyway. Doesn't feel like we're getting anywhere. Have a great day ;)
Evaluation in LLM applications is still an unsolved problem. Most teams rely on vibes-based assessment. Rigorous evaluation frameworks that correlate with real-world performance remain elusive.
Really cool to see things still being built in Haskell! How do you find using it compared to some of the newer languages that have more modern tooling?
Did you implement your own OAUTH2 flow in haskell for this?
For me, Haskell is the language of 2026. Having an agent available if you get stuck with some weird type error is a blessing. It also helps with the tooling. Though the modern tooling with cabal is pretty good.
it does through cabal and stack but its not as streamlined, quick, and versatile as tooling for languages like Golang or Rust imo.
I'm a huge fan of Haskell and I'm really exploring it as my primary language now that AI has gotten so huge, not just because it makes it easier but also because I can really lock down what I allow code to do (through pure functions, type checking etc) and so I feel a lot more confident in AI generated code
Sure, I find that with cabal and/or stack you often have to do things like manually add/link files for compilation and also both go mod and cargo support pulling libraries directly from Github say easily (using something like GO_PRIVATE), which I think is possible in cabal but you have to use project files which I never found intuitive. Also, just by virtue of having a smaller user base obviously the package ecosystem is smaller (this isnt the fault of the tooling) but in practice it means that community IDE plugins for things like autochecking for updates just aren't as good for Haskell.
The things above are definitely a skill issue on my part, I'm sure all of this is possible with cabal and stack and I may just not be using them right, but I definitely found cargo and go mod to be a lot simpler to get started with. Also, for cross-compilation and for FFI I found cabal to be a pain when including C sources where as Go was trivial through CGO (and the tooling around it was too).
For me personally (and also for everyone at work), I'm doing all package management with Nix. I'm happy with the setup. There is a learning curve with Nix, but as you can imagine this has shortened now with AI.
I mean, fixing small issues is not a big deal – during my ordering sessions, if something comes up, I actually just let Claude create an issue for it, and then when I have time, I create a fix.
I hope REWE is seeing this and offers an official MCP server. In the end we pay real money there. :D
I wrote a skill some time ago to support me with "agentic groceries" on my own - it's the future of shopping I would say.
My workflow:
- I paste in urls or text for receipts I will cook this week - agent extracts the ingredients, calculates cups to ml and such, replaces meat with vegi ingredients, replaces some other things I prefer always (often also creates a nice markdown receipe at this steo I can put into Obsidian) - check my list of favs, check search cache (so not every time the api is called, I'm a good netizen :D ) - ask me which items I have at home (no need to add to the basket) - search rewe api for multiple candidates and let me choose. - after each recipe I enter /new to start with fresh context - also I have a list of things I buy every week
I still put everything manually in the basket in the end, but this is not the thing which is time intensive.
This is also my exact workflow here. Thank you. I'm adding things that should be in the basket via Siri to my Obsidian notes. I also add recipes to that list or anything else. Then Claude checks that list once I want to do the shopping, looks through my favorites, and fills the baskets with all the items needed. I also use Claude to list the most frequently bought items for a template that always gets filled in.
Awesome. Are you exposing the api to Claude or just copy pasting the data for it to analyze? How are you feeding it the data?
It is extremely simple. I just tell Claude: "Use korb to look at my order history and create a table with my most frequently bought items. Next time, fill my basket with the items I always buy." So something of that variation works.
Thank you. Though I have to say I'm really not an expert in that domain and just starting to explore it myself.
Cool project, but have mixed feelings about publishing ever easier ways to access this API. They've locked down the API a while ago for a reason.
Also there already exists this reverse engineered project: https://github.com/ByteSizedMarius/rewerse-engineering/
I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option. I'm pretty sure this possibility is actually one of the reasons they locked down the API.
I've used Data from REWE in the past and made a comparison between a couple of cities in Germany (I believe it was Frankfurt, cologne, Berlin, Munich and Hamburg). Hamburg was by far the most expensive, often as much as 10-20% more expensive.
> I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option.
This is a great idea. I just think the use case is not that big since REWE is the worst in the price/quality ration and just going to another shop would save you more.
The existing project was a great inspiration and helped me figure out the mTLS stuff. I totally get your mixed feelings, though.
I really like your suggestion. I will put it in an issue and look into that. https://github.com/yannick-cw/korb/issues/4
Just to be clear, my mixed feelings don't come from a moral standpoint. Just hoping they don't lock it down any further heh ;-)
> Compare process across different markets.
Check out smhaggle app on Android
https://play.google.com/store/apps/details?id=com.smhaggle.a...
Oh nice, thank you. Will check it out later!
What I suspect though: They mainly show current discounts. The REWE API exposes those as a separate list for each market. There's around 3.5k markets and each can set their own discounts and has their own product catalogue with their own pricing.
So it would be 3.5k API calls to fetch all offers for all markets. Which is doable.
But fetching all products takes like 100 calls per market. It's quite a bit of data. And I think most supermarket don't publish their catalogue at all since they don't have delivery options.
2.8 rating in Play Store sounds bad
>I do have a suggestion for your app though: Have it compare your basket of goods across different markets in your region to show you the cheapest option.
I'd settle for just being able to sort items by unit price... I'm sure this is a [regulation-]solved problem in Germany though
> I'd settle for just being able to sort items by unit price
What do you mean? The official REWE app and website provide just that.
> I'm sure this is a [regulation-]solved problem in Germany though
Not sure what you mean by that.
Stores are required by law to provide the price per unit/weight/volume alongside the price, so you can directly compare the price of a pint of beer to the 0.33 liter bottle without calculating anything.
Ah thanks, didn't think about that.
I just checked and REWE only lets you sort by absolute price. But honestly, you can compare prices so much better on their website than in a physical supermarket already [0].
[0] https://www.rewe.de/shop/c/frisches-obst/?sorting=PRICE_DESC You have to enter a random zip code eg 20249
there is this "400g (1 kg = 3,48 €)" - would be pretty easy to sort results by that I'd guess, good idea!
An aggregator like this that could surface the same good for the cheapest price all inclusive of delivery would be something I would pay for!
As a SWE at Rewe (at a completely different department), I can say that I find this pretty cool. I wonder if this is going to be a wakeup to management to relax the API restrictions.
Please pitch internally for an official Rewe MCP server.
This is the future of doing groceries. Let us login with our credentials and let us do the search/filling the cart with agents.
Totally fine to do the payment only on the web, so everyone can be sure they only order what was wished, and not 300 avocados.
...or to tighten them.
You should tell them to charge for the API.
I mean, definitely leads to me buying more stuff on Rewe than before.
I want to add something else to this. In the process of writing this, I also played with formal verification and formally verified the suggestion engine, which was a really nice side discovery.
The basic idea is to write a prove in Lean4 and then test both the production implementation (Haskell) and the Lean implementation against random inputs. Compare if the results are the same.
If that is the case -> you can be pretty sure the unproven production version is as correct as the proven lean version.
https://www.dev-log.me/formal_verification_in_any_language_f...
This reminds me of pizza party cli app way back late 90s or early 2000
That's funny, I've just built the same thing for Asda in the UK https://github.com/markDunne/asdabot
It can search for items, add them to the basket, picks a delivery slot and does the checkout.
With a little more scaffolding in markdown files, this now takes care of my weekly shopping.
Even a CLI interface would be better than the sorry excuse of Asda's website. I wonder if entrusting an LLM is worth the trade off with the tedium of online shopping.
I want to use this but I literally have a Rewe 20 meters (at most) from the entrance to my building. Still I might give it a go considering all the positive comments in the thread.
Serious good use of an AI. Just let them do the grey area (like repeated purchase). I'd even let an algo pick better groceries for me. Cools tuff!
Absolutely. For example, I want to ask it: Suggest me some vegetables I haven't ordered in recent weeks or stuff like this, and this is all possible.
Ideally it should also look up if they are currently in season in your location, so many possibilities!
You can already filter by `isRegional`. That's maybe close enough.
Could even ask it to find recipes and then have it buy the ingredients needed for them next time it's doing your shopping!
Very cool! Thanks for sharing, I’ll try it out.
Haskell is indeed an interesting choice. ;)
the mTLS part is interesting. they're using it not for security in the traditional sense -- REWE knows what their own app is doing -- but as a fingerprinting mechanism. the client cert is how they distinguish their official app from third-party access. the weak point is that the cert has to live somewhere in the app binary, which is why mitmproxy can intercept it. it's less about encryption and more about making ToS enforcement slightly harder.
I love the idea of a CLI for groceries. Do you have plans to support 're-order' scripts or meal-plan integration? I can imagine a workflow where a recipes.yaml file gets piped into your CLI to automatically fill the cart with everything needed for the week. Much faster than clicking through a mobile UI.
Absolutely, that could just be a small script or something on top that calls the CLI tool
I remember a friend and I in college were looking into ways to do this in the US but major grocery chains here are pretty sensitive about their product data being accessible by open APIs and web scraping...
It would have been a cool project!
Surprised how little the B2C and even B2B e-commerce segment is providing API access for automation and agentic coding. One could easily set up rate limits, fraud detection and KYC checks upfront initial access.
Normal customers are not paying for APIs, so there is little value in offering them for free, especially when it can be harmful. B2B sometimes does pay for them, but not always is it obvious from the outside that they even exist. Much commerce is also on tight numbers and thus kinda secretive about their stuff.
Yeah, absolutely. I think internally, everyone is cooking up some gigantic commerce. This is just bringing it to myself a bit earlier.
B2B: Look at chefkoch.de They do use the REWE API, and I'm guessing not without their knowledge
B2C: Is it really surprising that a busines has no interest in providing more price transparency to their customers?
When Amazon launches an API everyone cries. Same story over and over. Even better example: TakeAway-Group. The perfect MITM.
Think it's context dependent whether it's a good or bad thing.
The owners of German supermarket and car companies are really the richest of the rich in Germany (okay and maybe the SAP guy on top). It would definitely be a net positive if someone manages to scrape and compare their prices.
In the restaurant market it's one player abusing many small players.
And honestly, I think the reason everyone cries when "Amazon launches an API" is because Amazon would not dare to piss off the German supermarket oligopoly.
> It would definitely be a net positive if someone manages to scrape and compare their prices.
There's a few projects doing that for DE / AT at least.
Can you share them? I recently looked for such projects and didn't really find anything that works well.
The issue is that each market sets their own prices and I believe REWE is the only large one where you can fairly easily scrape the product catalogue. I thought about it in a shopping list context, so you'd need to make it location dependent to be useful. But you could do a lot of cool things with it. Like choose a basket of goods and it creates a route for you: "Go to supermarket A and buy goods XYZ, then to supermarket B and buy ABC"
There's this one which got some publicity, doesn't seem to be updated any more but it worked for all these retailers listed and is open source: https://github.com/badlogic/heissepreise
https://www.supermarkt.at https://preisrunter.at https://sparpionier.com
> B2C: Is it really surprising that a busines has no interest in providing more price transparency to their customers?
Might I suggest you remove your tin-foil hat and consider that:
If you think about it, imagine if REWE officially exposed an API B2C. This would mean they are obligated to provide support.Do you really want the price of your shopping to increase because REWE now needs to find money to pay for a helpdesk for the millions of B2C API users ?
Businesses and services differentiating between B2C and B2B is nothing new, that is why the two different terminologies exist !
What next, you don't want to fill up your car at the petrol station (B2C) but you want to be permitted to buy a barrel crude oil direct from the drill and refine it yourself (B2B) ?
> Might I suggest you remove your tin-foil hat and consider that:
First up: Read and follow the rules. No need to insult me. Especially considering what you said shows that you both misunderstood AND misrepresented what I've said.
And frankly, my reasoning was simply saying "Company won't publicize internal info if they don't get an advantage from doing so". It's literally the same reason Google doesn't publish all of their source code. I'm struggling to see what part you are misunderstanding but it has to be something extremely basic to conclude I'm a conspiracy nut for basically stating "Company acts in their interest".
Opening an API to the public allows third parties to develop apps that can then be consumed by end-consumers. Not trying to be offensive here, but do you know what an API is? To conclude I meant every single end-consumers building their own app is at best disingenuously twisting my words.
Opening the API would allow new players like you and me to enter the market and take a piece of the pie. Why would a market, dominated and controlled by a few big players, opt for that? You don't even need to know that the German grocery market is incredibly price competitive, to understand that.
> If you think about it, imagine if REWE officially exposed an API B2C. This would mean they are obligated to provide support. Can you provide a source for that requirement? I'm pretty sure you just made that up.
> Businesses and services differentiating between B2C and B2B is nothing new, that is why the two different terminologies exist ! At this point I'm entirely lost what you read in my comment. Yes I know. I specifically made that distinction.
> What next, you don't want to fill up your car at the petrol station (B2C) but you want to be permitted to buy a barrel crude oil direct from the drill and refine it yourself (B2B) ? Yeah you definitely misunderstood something... What I said/meant:
The question: Why isn't the API open?
My answer: For B2B I gave an example where the API is used by another German firm, providing an example that the API is indeed consumed B2B.
For B2C: They have no reason to do so. They have a well functioning app where you can order stuff. They have one of the bigger recipe pages (at least it does very well SEO-wise) in Germany where you can immediately order ingredients from a recipe. The biggest recipe page in Germany (chefkoch) offers a direct link from recipes to their order page. Maybe you're missing this info? Thinking it's an internal API to data that isn't exposed anywhere at all would somehow explain whatever you tried to say here. But again, if you're that uninformed, don't insult people.
> Opening an API to the public allows third parties to develop apps that can then be consumed by end-consumers. Not trying to be offensive here, but do you know what an API is? To conclude I meant every single end-consumers building their own app is at best disingenuously twisting my words.
Here you are wrong too.
If you want to develop an app via an API that is only offered B2B, what do you do ?
Yes, that's right ...
You phone up REWE and negotiate a license to access to the B2B API to develop your application. B2B2C if you want to put it in simpler terms.
My original point stands. REWE clearly do not want to officially expose the API B2C, almost certainly for the exact reasons I already spelled out in my original post.
But no, its easier for you just to spread FUD, claiming "busines has no interest in providing more price transparency to their customers" just because they will not let you have access to the API as direct B2C.
Haha man, I think this is a cool project, the REWE API is cool, the REWE delivery App and Website are cool. Certainly not spreading fear, uncertainty or doubt.
What you describe as B2B2C is exactly what chefkoch does. And it's exactly what I initially said, so I'm not sure what point you're trying to make. But anyway. Doesn't feel like we're getting anywhere. Have a great day ;)
Really cool, but this is also how you end with 300 avocados and 500 L of detergent.
Well of course, how else am I going to make my Tideamole?
Nice! Do you know if the Austrian billa (REWE's subsidiary) is using the same api?
This could be helpful: https://heisse-preise.io
My friend works at Billa AT; I could ask her – but that would be cheating ;-)
What's the point of this comment!
this feels a bit like Sandra Bullock ordering pizza in „The Net“, impressive
Funny enough I was looking at rewe network requests for a personal app that suggests weekly meals and automatically orders the ingredients for you
Just pipe the items through this CLI, and you can save a ton of work :)
tell us more about it
It’s one step closer to have an agent to go shopping for my recipes or dinner, but hopefully unlike the Son of Anton
I am using it exactly like this. I tell Claude: "Add all things for this recipe to the basket."
supper cool, would be great if you can onboard different services.
> supper cool
Pun presumably intended?
Evaluation in LLM applications is still an unsolved problem. Most teams rely on vibes-based assessment. Rigorous evaluation frameworks that correlate with real-world performance remain elusive.
Really cool to see things still being built in Haskell! How do you find using it compared to some of the newer languages that have more modern tooling?
Did you implement your own OAUTH2 flow in haskell for this?
For me, Haskell is the language of 2026. Having an agent available if you get stuck with some weird type error is a blessing. It also helps with the tooling. Though the modern tooling with cabal is pretty good.
Does Haskell not have modern tooling? What would be considered modern in this context?
it does through cabal and stack but its not as streamlined, quick, and versatile as tooling for languages like Golang or Rust imo.
I'm a huge fan of Haskell and I'm really exploring it as my primary language now that AI has gotten so huge, not just because it makes it easier but also because I can really lock down what I allow code to do (through pure functions, type checking etc) and so I feel a lot more confident in AI generated code
Could you be specific? Saying it's not as "streamlined, quick, and versatile" is vague — I'm not really getting anything from that.
For context, I've been writing Haskell for quite a long time and I'm maintaining a few packages like Yesod.
Sure, I find that with cabal and/or stack you often have to do things like manually add/link files for compilation and also both go mod and cargo support pulling libraries directly from Github say easily (using something like GO_PRIVATE), which I think is possible in cabal but you have to use project files which I never found intuitive. Also, just by virtue of having a smaller user base obviously the package ecosystem is smaller (this isnt the fault of the tooling) but in practice it means that community IDE plugins for things like autochecking for updates just aren't as good for Haskell.
The things above are definitely a skill issue on my part, I'm sure all of this is possible with cabal and stack and I may just not be using them right, but I definitely found cargo and go mod to be a lot simpler to get started with. Also, for cross-compilation and for FFI I found cabal to be a pain when including C sources where as Go was trivial through CGO (and the tooling around it was too).
I love Haskell though so all good <3
Thanks for expanding on that.
For me personally (and also for everyone at work), I'm doing all package management with Nix. I'm happy with the setup. There is a learning curve with Nix, but as you can imagine this has shortened now with AI.
Love this! Super cool.
> Finally the best side projects are the ones you actually use and this one will be used for all my future grocery shopping.
Until it breaks in a few weeks.
I mean, fixing small issues is not a big deal – during my ordering sessions, if something comes up, I actually just let Claude create an issue for it, and then when I have time, I create a fix.
Well you don't control the API so it will still break.