DEV Community: Jait Ramadandi Jeke

I spent three weeks sourcing 500 perfume bottles by hand. Then I built an agent to do the job.

Jait Ramadandi Jeke — Mon, 31 Aug 2026 22:09:34 +0000

I wrote this post to enter the Google × Devpost **All Things Agentic*
hackathon (https://allthingsagentichackathon.devpost.com/). The project is SupplyMe,
submitted in the Taskmaster category*

I wanted 500 units of a 50ml fragrance made in Indonesia, on a first-batch
budget.

Five hundred is a small order, and small orders are where the B2B marketplaces
stop being useful to you. The factories I wanted were not listed on any of them.
The ones that were listed sorted by ad spend, and every number on every profile
was a form field somebody filled in once and never opened again.

So I did the job by hand. Three weeks, 41 tabs, three languages. My spreadsheet
had a column for minimum order quantity and nine of its rows said ?, because
most factories never publish one. I sent the same eight questions to one
supplier at a time and got answers to four of them.

Then two suppliers listed the same major fragrance brand as a customer.

I read both pages twice. They matched in every way that mattered to me: a logo,
a sentence, no date, no contract, nobody else saying it. One of those companies
was lying and I had no way in.

Sourcing information is disclosed, never published

A factory tells you its real minimum inside a negotiation and tells the next
buyer something else. No dataset holds that number. You learn it by asking, and
you learn whether it holds by finding somebody other than the factory saying it.

That is two different jobs. Read what a supplier publishes. Wait days for the
answer to what it does not. A search engine does the first badly and the second
not at all, and a chatbot stops existing the moment you close the tab.

What I built

The thing I built is called SupplyMe. You type a product into it — "500 × 50ml
EDP, Indonesia, premium packaging, minimise first-batch risk" — and then you
close the tab.

It breaks that product into the supply chain it needs, searches for real
manufacturers of each part, reads what they publish, and emails them what the
web could not answer. Days later, when a factory replies, it notices that the
price in the email is not the price on the website, puts both numbers back to
the supplier in a single follow-up, and ranks whoever survives.

Because a supplier can take three days to answer, nothing in the system waits in
memory for one. Every step is a persisted event, so a reply can arrive long
after the process that sent the email is gone and the mission still picks up
where it left off. That is the part that makes it an agent rather than a
conversation: it keeps working when you are not there.

What a claim is worth

The first thing I built is the part that answers my week-one question, and it
contains no model at all.

Gemini reads a page and extracts claims, stamping each one with where it came
from. A deterministic function turns those sources into a confidence — noisy-OR
with geometric decay:

CORROBORATION_DECAY, CONFIDENCE_CEILING = 0.55, 0.97
confidence = min(1 - math.prod((1 - w[i] * DECAY**i) for i in range(n)), CEILING)

The weights are the opinionated part:

Source	Weight
The supplier's own email	0.90
The brand's own website	0.85
The supplier's website	0.75
A Maps listing	0.55
A directory listing	0.45
A bare search result	0.30

Decay makes the second corroborating source count for less than the first and
the twentieth count for close to nothing, so twenty directory listings copying
one press release land under the manufacturer's own spec sheet. That 0.45 is
the marketplace problem I started with, written down as a constant.

One rule held the design together. Ask a model how confident it is and you get a
number that moves when you rephrase the prompt. Compute it from source identity
and you get one that moves when the evidence changes.

Ranking follows the same rule: a weighted sum over price, minimum-order fit,
capability, lead time, evidence strength and logistics, at 20/20/20/15/15/10.
Tell a mission to minimise first-batch risk and weight slides off price and onto
order-size fit. The agent that writes the recommendation receives a ranking it
did not compute and cannot reorder — hand it that power and the scores turn into
decoration.

Drawing that line meant I never had to build explainability, because the
explanation is the calculation. MOQ 500 fits an order of 500.

Six of my seven agents did not need to be agents

I started by wrapping everything in an LlmAgent, because that is what the
framework is for and it felt like cheating not to. Then I read the traces.

Six of them made one call and returned. One prompt, one schema, one response, no
branching, no tool choice. The workflow had already decided what happened next;
the model was filling in a shape.

The seventh looked like this against a real supplier:

read_page   https://kemasan-wangi.example.com/
search_web  "PT Kemasan Wangi Nusantara Indonesia 50ml glass perfume bottle MOQ"
read_page   https://kemasan-wangi.example.com/produk/botol-parfum-50ml

Nobody scripted that sequence. It landed on the homepage, could not find what it
needed, searched for the phrase that would surface a product page, and went back
for it. It returned moq = 500, quoted from "Minimum order: 500 pcs per
desain", and reported price and lead time as missing — which is what later
makes the system email this factory.

So research stayed an agent, with search_web, read_page and query_maps,
and the other six became single structured calls. A tool loop standing in for a
structured call gets you a slower and less predictable structured call at
roughly ten times the price. Working out where not to put an agent was the most
useful hour I spent.

What it costs to run

Measured from the API's own token counts, eight suppliers researched through to
a full recommendation cost $0.29, across 98 model calls and 562,287 input
tokens. Twelve suppliers costs $0.78, and that is the number I plan against.

Input tokens are nearly the whole bill, because one real supplier website runs
to tens of thousands of tokens and the research agent reads several per
supplier. Spend tracks how many suppliers you look at. How ambitious the brief
is barely moves it.

One saving worth stealing: reasoning tokens bill as output, and extraction does
not need them. Reading a price out of an email gains nothing from a thinking
budget. Capping it took the fast tier from 1,222 output tokens per call to 405.

Back to the two factories

SupplyMe still cannot tell me which one lied, and I no longer think that was the
right question. It reports one claim as corroborated by the brand's own site and
a trade publication, and the other as the supplier's word with nothing behind
it. Those two things arrive on my screen looking different, and I can click
either one through to the sentence it came from. In week one I would have taken
that over an answer.

Run it

Source: https://github.com/fillateo/SupplyMe
You can try it with no credentials and no spend (mock): MOCK=true docker compose up --build

Built with Google ADK, Gemini 3.5 Flash on Vertex AI, Cloud Run, Firestore,
Pub/Sub, Cloud Tasks, Cloud Scheduler, Secret Manager, Places, Gmail over SMTP
and IMAP, FastAPI, Next.js and OpenTofu.

Transforming an Old Laptop into a Local AI Chatbot with LLAMA3 and Open WebUI

Jait Ramadandi Jeke — Sun, 22 Dec 2024 20:21:54 +0000

In this post, I'll show you how I turned my old laptop, which I hadn't used in a while, into a local ChatGPT clone with just a few simple steps. Setting this up is straightforward and doesn’t require much effort.

Why Use a Local AI Chatbot?

Privacy: Your data stays local.
Customization: Fine-tune the model to fit your needs.
Flexibility: Use the AI as you see fit.

Steps to Set Up a Local AI Chatbot

1. Run Open WebUI via Docker

To make the installation easy, I'll use Docker to set up Open WebUI with bundled Ollama support.

Run the following command on your computer:

docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

This command will start Open WebUI. Once it's running, visit http://localhost:3000 in your browser and set up an admin user.

2. Install LLAMA3.2:1b

For this example, I’m using the llama3.2:1b model, but you can choose any other large language model (LLM) available on the Ollama site, depending on your needs.

In the top-left corner of Open WebUI, type the name of the model you want to install.
In my case, it’s llama3.2:1b.
Click Pull "llama3.2:1b" from Ollama.com.
Here’s an example of how it looks during the installation:

That's it! You can access your LLM (Large Language Model) from another device with the same network, using a local IP address like this example:

Once the model is installed, you can start using your local AI chatbot. Open WebUI supports multiple LLMs, so you can experiment with different models to find what works best for your needs.

What's next?

I'm planned to fine-tune LLAMA on my own dataset. So, wish me luck ;v

References

2 Things That I Started to Think in Reverse

Jait Ramadandi Jeke — Wed, 08 May 2024 05:09:52 +0000

A year ago, I bought a book written by Paul Arden titled "Whatever You Think, Think the Opposite". It's a simple book that teaches you that sometimes you need to think the opposite of other people or common ideas. As time went by, I came up with three things that I started to think about in reverse, which I'm going to write about in this article.

1. Set Goals That are Intended to Fail

Like many other folks, many times I set up a goal and it just didn't work out. Whether it's learning new things, building something, or my personal life, I started to wonder what was wrong with myself and began blaming myself for it. But now, I don't think the same way anymore.

So, here is what I do. What if you set up a goal but intended it to fail? I know it sounds cliché, but that's what I do now. The idea is, you have a goal, and when it fails, you have to find out why it failed and quickly learn from it. If the goal works, I will be happy. But if it fails, that is okay too, since I intended that goal to fail. So I don't blame myself anymore and don't feel down about it.

2. Being Productive is not all about adding something, but it's about removing something

I used to think that being productive means I can deliver more in terms of work. And that is true. But there is one thing that I forget about. The key to becoming productive is about removing something from your life. Being able to say no to things that are not your main priority or not really important. Removing distractions such as social media and some bad habits that can waste your time.

Being productive is not all about adding something to your life, but it's about removing things from your life. You can only do things that are right when you remove things that are wrong.

Conclusion

In wrapping up, let's take a look at what I've learned from these two ideas.

First off, we found out that setting goals with the expectation that they might fail isn't such a bad idea after all. Instead of seeing failure as a total disaster, we learned to see it as a chance to learn and grow. By embracing this mindset, we can shake off the fear of messing up and actually learn a ton from our mistakes.

And secondly, being productive isn't just about cramming more stuff into our schedules. It's also about clearing out the distractions and things that aren't important, which are holding us back. By cutting out distractions and focusing on what really matters, we can make room for the things that truly light us up.

So, in a nutshell, reverse thinking is all about flipping the script and trying out new ways of doing things. It's about embracing the unexpected and being open to unconventional ideas. And who knows? Maybe by thinking a little differently, we'll stumble upon some pretty cool solutions to life's challenges.

Why do we get frustrated when learning something?

Jait Ramadandi Jeke — Sat, 16 Sep 2023 07:35:57 +0000

When learning a new skill, we often reach a frustrating point, especially if you are a beginner, feeling that it's beyond our capabilities. We unconsciously give up before we actually quit. Boredom, panic, frustration, and insecurity are normal emotions in the process.

If you don’t feel frustrated while learning something, maybe you’re not learning. So, when you’re practicing some skills and you feel frustrated, that’s your weakness. So congratulations! You just know what your weakness is. In that moment, you started working on what you weren’t good at.

Learning is a painful process.

Pain is good for you. I know your tendency is to try to make it easy for yourself. Because at the end of the day, we are just human beings. We don’t like pain. So at some point, when you learn something and you feel it’s really easy to do and so much fun, you’re probably not learning. You’re trying to avoid your weaknesses.

The frustration is a sign of progress.

Frustration is a signal that your mind is processing complexity and requires more practice. Trusting this will all happen, you will allow the natural learning process to move forward, and everything else will fall into place.

So when you’re frustrated while learning, you don’t really know what you need to do. And that’s a signal on the way to a breakthrough. That moment you’re about to give up is where the magic happens. On the next day, all of the perfect solutions came to you. So, you only need to rest and chill a bit. Not quit.

Adopt the right mindset.

If you go that far, you will know that pain and frustration are good things. Once you know that, you are able to wait for the breakthrough that will come because you don’t give up.

You cannot change the topics that you’re learning to make them easier for you. But you can change your point of view. "Hmm, okay. This is my weakness; I need to work on it!". Adopting the right mindset is so important.

So remember, when you have that frustration, you are on the right path. Don’t give up!

Cara Membuat Output dari Query MongoDB Shell Menjadi Berwarna

Jait Ramadandi Jeke — Sat, 28 Aug 2021 15:12:17 +0000

Halo guys! Kali ini saya akan sharing tentang bagaimana cara merubah output dari query MongoDB Shell menjadi berwarna agar lebih nyaman untuk dibaca. Untuk melakukan itu kita akan menggunakan sebuah shell extension yang bernama Mongo-Hacker.

Untuk menginstallnya, kita hanya butuh 4 langkah berikut:

Step 1: Clone repository dari Mongo-Hacker

git clone https://github.com/TylerBrock/mongo-hacker

Step 2: Masuk kedalam folder mongo-hacker

cd mongo-hacker

Step 3: Install package

make install

Step 4: Bersikan folder

cd ..
rm -rdf mongo-hacker/

Selesai!