This interview is with Luis Haberlin, AI Food Tech Specialist, Comi AI.
For readers meeting you on Connectively, how do you describe your work as an AI Food Tech Specialist and founder of Comi AI and the specific nutrition‑tracking problems you focus on?
I build Comi AI, an app that analyzes a plate of food from a single photo and returns calories and macronutrients.
It’s built for Latin American food first — not the U.S. and Western diets that most food AI was trained on.
Most calorie apps choke on a plate of bandeja paisa or a tamal tolimense. They either can’t name the dish or they flatten it into a generic ‘stew.’ I focus on the long tail of regional food that global tools ignore.
The problem I care about most isn’t naming the dish. My models achieve about 93% accuracy in identifying the item. The hard part is portion size: whether a photo shows 180 grams of rice or 320 grams is where most trackers quietly fail, and it’s where the real calorie count lives.
The work is two jobs:
- Teach a model to recognize food a Colombian grandmother would recognize.
- Stay honest about grams instead of pretending a photo gives a perfect weight.
The takeaway: a calorie tracker is only as good as its worst guess on portion size, not its best guess on the name.
Looking back, what pivotal experiences led you into AI for food—particularly Latin American cuisine—and shaped how you build today?
What pulled me in was a gap, not a single lightning moment. Mainstream calorie apps are built on U.S. and Western food data. Point them at a Colombian plate and they fall apart.
I kept seeing the same pattern. Someone logs breakfast, the app offers “scrambled eggs, 200 calories,” and ignores the arepa, the cheese, the hot chocolate next to it. The person quits within a week—not for lack of discipline, but because the tool never spoke their food.
That reframed the whole problem for me. Food AI isn’t one problem; it’s two: recognition and portioning. Recognition is mostly solved for burgers and salads; it’s wide open for lechona, mondongo, and a hundred regional dishes that never made it into a training set.
The portion side shaped how I build even more. A photo doesn’t give you grams, so I stopped chasing a magic number and started designing for honest ranges and fast corrections. That respects the user more than a confidently wrong answer.
So the pivotal experience wasn’t a meal; it was noticing that a whole region of eaters was treated as an edge case. Now I build for that edge case on purpose.
Building on your choice of scanning over photos, when you prioritized barcode scanning to crush logging friction, what concrete signals or experiments convinced you that Ai Escanea was the right first move?
I’ll gently correct the premise because it’s the heart of the bet. The first move was photo scanning, not barcodes, and the reason is exactly the food I care about.
A barcode needs a package. Most of what people eat in Colombia has no package: a plate of bandeja paisa, a tamal from a street vendor, lunch at the corner spot. There’s no barcode to scan, ever. If I’d led with barcodes, I’d have nailed the food we’re least interested in and missed the food we exist for.
So the signal wasn’t a clever experiment; it was a structural fact. Packaged, barcoded food is the well-served part of the market. Fresh, home-cooked, regional food is the gap. You build for the gap.
Barcodes are genuinely useful for packaged goods—the boxed cereal or a labeled Chocoramo—but that’s a convenience for food that’s already easy to log. It can’t be the foundation when the core meal on the plate has no label at all.
The rule I follow: solve the hard input first. The easy input can bolt on later. Do it the other way and you’ve built a great tool for a problem someone already solved.
Staying with localization, how did you design the data and labeling pipeline that lets your Comida IA reliably recognize dishes like lechona, tamales tolimenses, and sancocho in production?
The core insight: you can’t label Latin food with labelers who’ve never eaten it. Sancocho and mondongo look alike in a photo if you don’t know the difference. So the pipeline starts with people who grew up with the food, not a generic crowd-labeling queue.
Three things matter most.
- Regional granularity. “Tamal” isn’t one label. A tamal tolimense, a tamal santandereano, and a tamal valluno are different foods with different macros. If you collapse them into one label, the calories are wrong before the model even runs.
- The long tail. Lechona and sancocho aren’t rare to a Colombian, but they’re nearly invisible in global food datasets. So we over-sample the dishes commodity APIs miss instead of chasing another thousand photos of a hamburger.
- Honest failure modes. A dish shot as leftovers in a plastic container looks nothing like the same dish plated fresh. The pipeline must see both, or it only works in food-blog lighting.
Recognition sits around 93% on the dishes we’ve targeted. The one I won’t dress up is portion size. That’s the frontier, and no labeling trick fully solves it yet.
The principle: recognition is a data problem you fix with the right people labeling the right foods. Portion is a physics problem. Don’t confuse the two.
Next, given that portion size is the hardest variable, how do you quantify and communicate uncertainty in grams and calories in a way that increases user trust and adherence?
The worst thing a calorie app can do is show “just 542 calories” with fake confidence. That number is a guess wearing a lab coat. The moment a user catches it lying, they stop trusting every number after it.
So I treat the estimate as a starting point, not a verdict. A few principles.
-
Show a sensible default, then make correcting it a single tap. Most people know if the plate was a light lunch or a heavy one. Let them say so in one gesture, and the calories update.
-
Anchor portions to things people can picture: a serving the size of a fist, two spoonfuls, half a cup. That’s easier to confirm than “180 grams,” which almost nobody can eyeball.
-
Be upfront that portion is the soft spot. Recognition is strong. Grams from a flat photo are an estimate, and I’d rather say that than fake a decimal. Honesty there buys more trust than false precision ever does.
-
Optimize for consistency over perfection. If the estimate runs a little high every day, the trend is still useful. A tracker that’s directionally right and easy to correct beats one that’s occasionally exact and often absurd.
The rule: users forgive an honest range. They never forgive a confident wrong number.
Switching to your produce‑quality model, what constraints on real phones in Colombia (lighting, latency, model size) most shaped the system, and how did you overcome them at the moment of user scanning?
Quick reframe: the model that matters here is meal recognition, not a separate produce grader. The phone constraints are very real, and they shaped much of the system.
The biggest one is that our user isn’t on a flagship device. Assume a mid-range Android, a few years old, on a spotty connection. If the app only feels good on a new iPhone with strong Wi-Fi, it’s built for the wrong person.
Lighting is the daily enemy. Food gets photographed under yellow kitchen bulbs, in a dim comedor, on a phone with a smudged lens. A model trained on clean studio shots looks brilliant in a demo and falls apart at an actual lunch table. So the training data has to include the ugly real-world photo, not just the pretty one.
Latency shapes trust more than accuracy does. If a scan takes eight seconds, people stop scanning. The target is a result fast enough that logging a meal feels lighter than typing it. That pushes work toward a lean model, not a heavy round trip for every photo.
The rule I keep coming back to: build for the phone your user actually holds, in the light they actually eat in. The lab is not the lunch table.
Zooming out to barcode data ops, across EAN/UPC variance and frequent product reformulations, what operating model do you use to source, verify, and keep nutrition facts accurate at scale in Latin America?
Two honest points up front:
On the packaged side, the trap is treating a nutrition database as if its finished. It never is. Products get reformulated, labels change, and the same product carries different codes across countries. So I treat the data as perishable. Entries have a freshness age; high-traffic items get re-checked more than the long tail, and a user flagging a wrong label is a signal, not a nuisance.
The Pareto reality helps: a small set of products makes up most scans. You verify those hard and often instead of pretending you can keep a million rarely-touched entries perfect.
But heres the part people miss. For the food Comi exists to handle—a plate of home-cooked Latin food—there is no manufacturer label to source. Accuracy there doesnt come from a barcode feed at all. It comes from solid reference values for common regional dishes, built with people who know how those dishes are really made.
So the operating model is split: packaged foodkeep it honest by assuming it rots; real foodget the reference dish right, then estimate the portion. The mistake is thinking one operating model covers both.
Turning to Apple Watch, which specific micro‑interactions, complications, or voice flows have actually made meal logging a true 10‑second habit for your users?
Honest answer: I’m not going to invent an Apple Watch story. Our first user isn’t wearing one. She’s on a mid-range Android phone in Colombia, and that’s who I design the habit for.
But the real question underneath is right. What makes logging a true ten-second habit? A few things, and none of them are gadgets.
- Kill the typing. The whole reason for photo-first is that a picture beats searching a database for “arepa con queso” and scrolling forty results. Point, shoot, done. Typing is where food logging goes to die.
- Make the default good enough to accept. If the first result is usually right, the habit is one tap. If it’s usually wrong, every meal becomes a chore and people quit by Friday.
- Protect the streak, not the perfection. A fast, roughly-right log someone actually does every day beats a precise log they abandon. Consistency is the feature.
If a wearable ever makes sense, the bar is simple. It has to make the ten seconds shorter, not add a screen. Most “smart” logging flows add taps while claiming to remove them.
The rule: the habit isn’t built by more surfaces. It’s built by removing the one step people hate, which is typing.
Looking ahead, what is one near‑term experiment you plan to run that tests your view on how Ai Escanea, on‑device vision, and wearables will reshape everyday eating over the next 24 months?
The experiment I most want to run is about portion size, because that’s the honest weak spot. Estimating grams from a flat photo is closer to a coin flip than I’d like.
My hypothesis is that a tiny bit of human input beats a fancier model. Specifically, a single reference in the frame: a hand, a standard spoon, or a common plate—something the vision system can use for scale.
So the test is simple: two groups log the same real meals. One takes a plain photo; the other includes a known reference object. Then compare estimated grams against actual weighed grams, and, just as important, compare who is still logging a week later.
I have a real prediction, and I’m willing to be wrong. I think the reference-object flow wins on accuracy but loses on habit, because staging a photo adds friction. If that’s true, the answer isn’t “force the reference.” It’s to make it optional for people who want precision and invisible for everyone else.
On wearables, my honest view for the next 24 months is modest. The camera already in your pocket reshapes everyday eating long before a watch does, at least for our user.
The rule I test against is: don’t add a step unless the accuracy it buys survives contact with a busy person’s real day.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
Just one idea I’d leave people with:
Most technology quietly decides whose life it’s built for, and food AI decided early that the default eater was American. Everyone else became an edge case.
Comi is a small bet against that. If a tool can understand a plate of bandeja paisa as fluently as it understands a chicken salad, then millions of people who were told “your food isn’t in the database” finally get counted.
I’d rather the app be honest than impressive. It’s strong at knowing what the food is, and it’s humble about exactly how many grams are on the plate. Users handle that honesty far better than a confident wrong number, and they reward you for it.
If you build in health or food tech, the takeaway is this: Serve the people the big datasets skipped, and tell the truth about what your model doesn’t know yet. That’s a better moat than pretending to be perfect.