It’s been a bit less than a year since I left my job to work on my own projects, and most of that time I’ve been building with AI. For the last six months or so, that mostly means Claude.

Today I have two products with real users. iWish is a free platform to create a page for your event, with invitation, RSVP, gift list and photo album, all in one place. Guaxí is an app for doctors who work in several places, to keep shifts, appointments and payments organized. (Yes, Guaxí comes from guaxinim. The raccoon is back.)

Back in 2024 I wrote about how I was using AI day to day, mostly for small productivity tasks. A lot has changed since then.

The programming part got really fast. But there’s one thing I can’t stop noticing: almost every interface built with AI looks the same. Same kind of buttons, same page layout, similar fonts, even similar copy. You open a new site and think “yep, an AI made this”.

If you don’t give the model much guidance, that’s what you get. And I’m not a designer (if you read my coffee barista post, you already know my apologies to all designers out there are a recurring thing).

Recently, I came across this post on UX Planet, where the author tests three Claude Code skills for web design. I recommend reading it. It gave me the push to run my own version of the test, using a project of my own.

So I wanted to answer a simple question:

if you don’t have a design background, can skills help you get out of the default look?

This is the first of a couple of posts about what I’ve learned building with AI this year. This one is only about interfaces. The next one will cover how I organize files and projects for agents, and how the developer role is changing.

The Experiment

My first idea was to test this on my own projects. But they already have a branding file and interface definitions that the agent reads every time it touches design. That’s great for consistency, but it leaves very little room for a skill to change anything.

So I started from scratch, with a new project. And since I’m me, it’s about coffee.

Coffee Nerds

Coffee Nerds is an app for coffee geeks. You can find famous coffee recipes, brew them, and log the result: “I made this recipe with this specific coffee and it was great” (or not so great).

To keep the comparison fair, every version got exactly the same inputs:

• PROJECT.md, a single markdown file with the vision, target users, the data model (coffee, method, recipe and brew log) and six well-known recipes as seed data, like James Hoffmann’s V60 and Tetsu Kasuya’s 4:6 method. This is the only context every version received.
• The same model: Claude Opus 5.5.
• The same execution prompt.

Everything is on GitHub: lfomendes/guaxinim-tests. Each design lives in its own branch, so you can check out any version and compare them yourself.

The two skills

If you haven’t used them yet, a skill is basically a set of instructions the agent loads when it’s doing a specific kind of task (if agents are new to you, I wrote a short intro in Weekly reading: AI Agents). Think of it as a style guide plus a checklist that the model reads before it starts working. I picked two design skills:

• Taste Skill: focused on pushing the agent away from generic, boilerplate UI and toward more deliberate choices in layout, typography, spacing and motion.
• UI UX Pro Max: a broader design guide for web and mobile, with visual styles, color palettes and UX guidelines.

Four versions

Besides the two skills, I ran two reference versions. One with no skill at all, just telling Claude “execute this”, which is exactly the look I’m trying to escape. And one with no skill but using Claude Design, to see how much the design feature alone changes things.

So, four versions in total, one run each, each in its own branch:

The results

Now I’m going to show what each version looks like. The goal here is not to crown a winner. It’s to compare what each combination produces and how far it gets from the default.

1. Default (no skill)

Let’s start with the reference: same spec, same prompt, nothing else. (branch)

This is the look you’ve probably seen a hundred times by now: warm off-white background, a red pill button for the main action, rounded cards, four stat tiles at the top, little pill badges and star ratings. It’s clean and it works. There are even some nice touches, like a monospaced font for dates and a dark card for the best cup.

But put it next to any other AI-built app and you’ll see the family resemblance.

2. Claude Design (no skill)

Same spec, no skill, but using Claude Design. (branch)

Honestly, I expected more difference here. Claude Design organized the page better, putting the stats right next to the main message, and the hierarchy is clearer. But the visual language is basically the same as the default: same red, same rounded cards, same stat tiles, same pills. Side by side, they look like siblings.

One note: the headline text is the same in both because I used a shared sample data file to fill the screens. That part is on me, not on the AI.

3. Taste Skill

(branch)

This is the one that surprised me. It went for an editorial, almost brutalist look: black-and-white coffee photos (including an old one from a coffee harvest in São Paulo), flat color blocks, huge uppercase type and no rounded cards anywhere. Nobody would look at this and think “AI made this”.

It also packaged the app differently. Instead of opening straight into the journal like the others, it built a website with a big landing page up front. But don’t be fooled by the first screen: everything I asked for in the spec is there, the recipes, the brew timers and logging your cup. It didn’t ignore the brief, it just chose a very different way to present it.

And it got everything by its own, all the images, the video, the animation. I really enjoyed the final product.

4. UI UX Pro Max

This one feels like a real product with its own personality. Sidebar navigation instead of the top bar, serif headings, a brown and caramel palette that actually feels like coffee, and monospaced numbers for the recipe details.

Under the hood, though, it still uses the usual building blocks: cards, pills, stars and the same sections. It also generated a design system and a style guide along the way, which is exactly the kind of file I’d want to keep the project consistent from here on.

What I took from it

Short version: Claude Design alone didn’t get me out of the default look. The skills did, in very different ways.

• Claude Design improved the layout, but kept the same visual language as the default.
• UI UX Pro Max gave the app a personality while staying inside the usual app conventions. It’s the safer choice if you’re building something people use every day.
• Taste Skill was the only one that really broke the pattern. It wrapped the app in a website with a landing page up front, but still delivered every feature in the spec, recipes and timers included.

Another thing became clear looking at them side by side. The three app screens have almost the same sections (bags on the shelf, best brews, recent brews), because they all came from the same PROJECT.md. The spec decided the structure; the skill decided the look. That makes me even more convinced that your project files matter more than your prompt, but that’s a topic for the next post.

A few things I already believed before the test, and still do:

• If you have a designer, use a designer. Someone with that background can write a proper definition file with patterns, colors, fonts and examples. That will beat any skill. This test is for the rest of us.
• Ask for options early. At the start of a project, asking Claude for three different designs is one of the easiest ways to steer the visual direction. It’s much easier to react to options than to describe what you want from nothing.
• Then lock it down. Once the project is moving, the goal flips from variety to consistency. That’s why I keep design and branding files in my projects, and the agent reads them every time it touches the UI. I’ll talk more about that in the next post.

Limitations

I used both skills in the simplest way possible: one prompt and let it run. These libraries probably have more features, and they likely work better in a more iterative process, going back and forth with the agent. So take this as a “from zero” comparison, not a full review of either skill.

Also, this is one project, one prompt and one run per version. Run it again tomorrow and you’ll probably get something a bit different.

What’s next

The next step is to use two of these skills in my real projects, asking for a new page or a new feature. I want to see how they behave when there’s already a project definition and a brand file in place, which is the situation most of us are actually in.

Wrapping up

AI made building the app the easy part. Making it look like your app, and not like every other AI-built site out there, is still on us. Skills seem like a good shortcut for people like me without a design background, but they don’t replace knowing what you want.

If you’ve been using other design skills, or have tricks to get Claude out of its default look, I’d love to hear about them. Feel free to leave any questions or suggestions in the comments.

And if you want to see what came out of a year building this way (with design files, not skills, at least for now), take a look at iWish and Guaxí. Feedback is very welcome there too.

And if you want to try it yourself, the repo is here. Start from PROJECT.md, pick your favorite skill, and see what you get. Each of my versions is in its own branch if you want to compare.

This text was reviewed with the help of an LLM.

Personal Hub: Learn more about my work and latest indie projects at guaxinimapps.pages.dev.

Even though I’m not working directly with Recommendation Systems at the moment, I always make time to follow how production AI architectures are evolving. Continuous learning is essential in ML engineering, and Netflix’s latest post on GenRec (their LLM-native recommendation ranker) was an incredible read!

Here are a few key takeaways that stood out to me:

🔹 Off-the-shelf LLMs aren’t production-ready RecSys

Standard foundation models tend to hallucinate out-of-catalog items, over-recommend globally popular content, and ignore business constraints. GenRec addresses this by post-training an open-source backbone on Netflix-specific data, matching or exceeding mature production systems with far fewer labeled examples.

🔹 From Feature Engineering to Context Engineering

We’re seeing a paradigm shift: “The prompt becomes the new feature vector.” Instead of designing manual feature vectors, Netflix verbalizes user interaction logs and metadata into natural language conversations. Modeling effort shifts to deciding what context to include, how far back to go, and how to stay within a token budget.

🔹 A Smart Two-Phase Architecture

• Phase 1 (Foundation): Adapts an open-source base LLM to domain-specific Netflix content and member patterns. Updated infrequently, it serves as a shared backbone.
• Phase 2 (GenRec Ranker): Post-trains the backbone specifically for candidate ranking and steering. Refreshed frequently to capture evolving tastes and content additions under strict serving cost limits.

🔹 Prefill-Only Inference (Game Changer for Latency)

Autoregressive token-by-token generation across thousands of items would be way too slow and expensive for real-time recommendations. Netflix bypasses generation entirely: the LLM consumes the prompt once in prefill mode, scoring the candidate set in a single GPU forward pass!

🔹 Multi-Objective Loss & Long-Term Alignment

Training combines ranking loss, language modeling loss (preserving text understanding and explanation potential), and reward-weighted loss. This ensures recommendations align with broader business goals: balancing movies, series, live shows, and games while optimizing for long-term member satisfaction rather than short-term clickbait.

Generative AI isn’t just about generating text, when paired with clever system architecture and inference tricks, foundation models can completely transform high-throughput ranking systems at scale.

Final Thoughts

LLMs have transformed almost every corner of AI over the past couple of years, but recommendations always felt like a particularly tough area to tackle. The obstacles felt overwhelming: high inference costs, strict real-time latency budgets, model scale, and the notorious difficulty of translating offline metric wins into actual online impact.

To be honest, I was pretty pessimistic about LLMs playing a meaningful role in production RecSys anytime soon. However, seeing architectures like GenRec shows that with clever engineering, especially around context compression and prefill-only serving we really can merge the best of traditional RecSys with the reasoning power of LLMs.

🇧🇷 Para os leitores brasileiros: conheça meu trabalho atual

Para quem é do Brasil e quer acompanhar o que venho construindo recentemente como indie developer, confira alguns dos produtos que lancei:

• 🎈 iWish Gifts: Plataforma para simplificar listas de presentes e vaquinhas de aniversários, chás de bebê e eventos.
• 🎁 entre nós: O “Wrapped” para casais : transforme seu histórico de conversas do WhatsApp em um presente visual inesquecível.
• 🩺 Guaxi: Gestão financeira descomplicada para profissionais de saúde autônomos acompanharem plantões e repasses de convênios.

Confira todos esses projetos e meus artigos no meu portal central: guaxinimapps.pages.dev.

A while ago I was doing something pretty boring: going through the list of new signups for one of my projects. I have three of them running in parallel right now, all at least in beta with real users, so this kind of housekeeping is part of my weekends.

Then I noticed something odd. A lot of those accounts weren’t people. At one point I had more bots signing up than actual humans.

I ended up changing the application just to add some friction and verify there was a person on the other side.

Crawlers have always existed, anyone who has ever run a website knows that. But today’s bots are smarter, cheaper to run, and much harder to block.

Then in June, Cloudflare’s CEO posted a chart showing that automated requests had overtaken human ones on the web for the first time: something like 57% bots to 43% humans, arriving years earlier than he had predicted. Measuring this is messy and different providers report very different numbers, so I’d take the exact percentage with a grain of salt. But it made my little signup problem feel less like a bug in my app and more like a symptom.

That has been rattling around my head ever since, because it connects to something bigger I’ve been trying to put into words.

The loop

I’m currently reading The Infinity Machine, Sebastian Mallaby’s book about Demis Hassabis and DeepMind, and while I was in the middle of it two news items showed up in my feed.

The first was Anthropic buying physical books, cutting off the bindings, and scanning them page by page to train models. The second was a term I keep running into: “Google Zero”, a phrase Nilay Patel coined at The Verge for the endpoint where AI summaries answer your question right there on the results page and the traffic to the original site goes to roughly nothing.

That endpoint stopped being theoretical this month. The New York Times ran a piece on how Google is building an AI fence around the internet it once defended, and the Wall Street Journal reported that Reddit, USA Today, Reuters, Politico and The Economist are all seriously considering blocking Google’s crawlers, the reported traffic declines vary a lot depending on who’s measuring, but Business Insider’s drop is somewhere north of 85%.

Read that again, because it’s genuinely strange. Publishers are considering making themselves invisible to the largest search engine on earth, because being visible no longer pays.

Put all of it next to my bot signups and a pattern shows up.

We’re entering a loop where AI generates the content and AI consumes it. Bots writing, bots reading, and humans somewhere in the middle, increasingly optional.

I should be honest about my own part in this. I use AI when I write these posts, mostly to organize a messy pile of ideas into something with a beginning and an end. But I curate, read, rewrite, and adjust everything myself. What ends up published here reflects things I actually think.

That’s a different thing from what a growing share of the web is becoming: agents that watch trending topics, scrape what already exists, and publish articles automatically, at a volume no human team could ever match.

When content becomes free

Set aside for a moment the bigger debates around AI ethics, synthetic video, and elections. The part that keeps pulling my attention is simpler and more structural: we are about to be flooded. First with text, then images, then video, pushed by the cost of producing all of it falling toward zero.

And when content becomes almost free to produce, basic information gets commoditized.

If I search for the population of Ecuador, I get the number immediately. No click, no visit, no ad impression. Great for me. But what happens to the site that compiled that data and depended on that traffic to exist?

This is the part I don’t think we’ve fully priced in. The internet as we know it was built on an economic loop:

• search engines send traffic,
• traffic pays for the content
• the content feeds the search engines.

AI answers break the middle link of that chain while still depending on the last one.

Which brings me to the conclusion I keep arriving at.

Human-created work is becoming the premium tier.

You can already see it. If you need a quick image for a blog post, AI generation is usually good enough. But whoever has the budget still hires a human artist, for the technique, the quality, and the creative direction. The same is happening with writing: serious outlets are putting human journalism behind paywalls, precisely because it costs more to produce.

AI becomes the default option for the masses. Human touch, expertise, and craft get reserved for the top of the pyramid. I’m not sure I love that outcome, but I have a hard time seeing the incentives pointing anywhere else.

So what do we actually do?

Honestly, I don’t have a clean answer, and I’m suspicious of anyone who does.

But there are two things I’ve been arguing for a long time now. The first is regulation. These tools are going to need it, and I think it’s inevitable. If search engines stop sending traffic to the sites whose content powers their answers, there should be some obligation to compensate the people who created it.

The second is that we need decent frameworks to verify whether content is authentic and human-made. Not a perfect solution, I don’t think a perfect one exists but something better than “trust me.”

At the individual level, the lever is smaller and simpler: intentionally look for and support human-generated work. Pay for the newsletter. Buy the book. Follow the person, not the feed.

The pendulum

The optimistic part is that the reaction is already visible.

Book clubs and physical media groups are growing again: people meeting online or in person to read paper books written by humans and talk about them together. My guess is that platforms will eventually adopt explicit badges saying something like “this was made by a human”, the same way we got organic food labels.

Society tends to work like a pendulum. As AI floods the market, I think it swings back toward valuing human authenticity and that’s a swing worth helping along.

I’m still figuring out what that means for the products I build, and I’ll probably change my mind about parts of this over the next year. But the bot signups made it concrete for me in a way that no think-piece had, and that seemed worth writing down.

Sources

Everything I referenced above, in case you want to go to the originals, which, given the subject of this post, feels like the least I can do:

• The Infinity Machine: Demis Hassabis, DeepMind, and the Quest for Superintelligence, Sebastian Mallaby (2026) — Goodreads
• “Google Is Building an A.I. Fence Around the Internet It Once Defended” — The New York Times
• Reddit and news publishers weighing whether to cut off Google — The Wall Street Journal (and the New York Post summary, if you hit the paywall)
• The original “Google Zero” framing, by Nilay Patel — The Verge
• Bot vs. human traffic, and the crawl-to-refer ratios — The Cloudflare Blog
• I also found this video a good walkthrough of the Google Zero story if you’d rather watch than read.

If you’d rather listen

I’ve been turning these posts into short audio episodes: same ideas, more conversational, made for walks and commutes. It’s called GuaxiCast, and you can find it on Spotify or through the RSS feed.

Para os leitores brasileiros ☕

The apps I mentioned are all Brazil-first, so if you’re reading from here, these are what I’m currently building. All of them live at guaxinimapps.pages.dev:

• entre nós — turns a WhatsApp conversation into a visual gift: message counts, most-used words, favorite emojis, the whole timeline of a relationship. Basically a Wrapped for couples.
• iWish Gifts — gift registries and group gifting for baby showers, birthdays, and everything in between. This one scratched a very personal itch.
• Guaxi — for autonomous health professionals: all the money from shifts and insurance plans in one place, so you know exactly when each payment lands.

And yes, the raccoon is still around.

A few months ago, I made a decision that scared me a little: I left my stable job and took a sabbatical.

Most of it was about rest and reflection. But it was also about curiosity. I wanted to go back to the thing I love most — creating stuff. And I wanted to do it in this new world where AI is sitting right next to you at the keyboard.

(If you want the full story of what I learned during my time off, check out [my sabbatical post — link here].)

Four projects later…

I didn’t just play around. I actually shipped things.

(if you wanna follow my projects I’m adding all of them here -> https://guaxinimapps.pages.dev)

One project was for a friend in the medical field — a more private one. Another was an anniversary gift (yes, I built software as a gift).

On is in beta and two of them are open (updated on may 29th 2026) right now, and I’m genuinely excited to share them, but I’m sorry for my international readers, both of them are focused on Brazilian customers.

iWish — A platform designed to simplify organization for social events like baby showers. Currently in Open Beta.

Guaxinim Finanças — Yes, raccoons again. If you’ve read my coffee barista posts, you know I have a thing for guaxinins. This one is a personal finance app built with a minimalist UX — quick expense tracking, financial health at a glance, no noise. Also in beta, but this one’s a closed beta for now.

entre nós (entrenos.iwish.gifts) — It turns a couple’s WhatsApp or Telegram conversation into a beautiful animated keepsake — a “retrospective” of the relationship, with the real numbers: total messages, who wrote more, first message date, most-used words.

All of them are real products, used by real people, and built mostly by me — with a lot of AI help.

Which brings me to what this post is actually about.

What I learned building with AI (the honest version)

You ship more. A lot more. But there’s a catch.

This part is real — AI coding genuinely multiplies your output. Features that would have taken me days came together in hours. The ceiling of what a solo developer can build has moved significantly.

But here’s what nobody tells you upfront: you need more structure, not less.

When you’re writing code yourself, the architecture lives in your head. You feel the inconsistencies. With AI helping, you can move so fast that the codebase becomes incoherent before you notice. I learned to invest more time upfront in documentation, planning, and defining patterns.

Think of it like hiring a very fast contractor. They’ll build whatever you describe. The better your blueprints, the better your building.

AI dev is expensive

If you’re coding with AI casually, the paid tiers of Claude, ChatGPT, or Windsurf are fine. But if you’re building full time? You will burn through credits embarrassingly fast.

The “max versions” are much more expensive. I’m talking somewhere around $200/monreth — that’s over R$1.000 just to keep the lights on for your AI tooling. That’s not sustainable for independent developers, and it’s something companies should think seriously about. Either pay for the max tier for developers who actually use these tools, or accept that your team is either context-switching constantly or paying out of pocket.

One thing that helped me a lot — and I touched on this in a previous post, is being intentional about which model you use for which task. Not every step in your workflow needs the most powerful (and most expensive) model. A pattern that worked well for me with Claude models as examples.

• Opus for the heavy thinking: research, architecture decisions, writing a detailed markdown spec for a new feature.
• Sonnet to read that spec and produce a concrete development plan — it has the context it needs, the hard thinking is already done.
• Haiku for the actual implementation of well-defined tasks — fast, cheap, and perfectly capable when the instructions are clear.

You’re essentially using the expensive model to produce a compressed, high-quality brief, and then letting cheaper models do the execution. The cost difference is significant.

And there’s one more trick that compounds this: use separate sessions for each phase. It sounds simple, but it matters. Each session starts with a clean context window. If you carry everything into one long conversation — the research, the planning, the implementation — you’re paying to re-process all that context on every single message. Splitting by phase keeps each session lean and focused, which is both cheaper and, honestly, produces better results because the model isn’t wading through irrelevant history.

Learn the meta-layer: Skills, Rules, Agents, Workflows

This one changed how I work more than anything else.

There’s a layer above just “chatting with AI to write code” that most people skip. Tools like Windsurf introduced the concept of agents.md — a file where you define how the AI agent should behave in that folder.

“This is particularly useful for providing directory-specific coding guidelines, architectural decisions, or project conventions.”

But the honest origin of this pattern is Claude. Anthropic started the conversation around structuring AI behavior through explicit instructions and context — the idea that you’re not just prompting, you’re configuring a collaborator. Windsurf and others built on top of that thinking.

Skills are reusable capabilities you define once and invoke repeatedly. Workflows are sequences the AI follows for repeated tasks. Rules are guardrails that keep the AI consistent with your codebase’s personality.

Once I started thinking in these terms — not “what do I ask the AI?” but “how do I set up the AI to work well with me on this project?” — everything got better. Less repetition, fewer corrections, more flow.

Here’s a real example from iWish. Every time I touched a database model or schema file, the AI needed to know: use Alembic for migrations, always test the downgrade, never use datetime.now(). Instead of repeating that every single time, I defined it once as a skill:

---
name: db-migration
description: MUST be invoked before any SQLAlchemy model change, new table,
new column, new enum, or Alembic migration file. 
Use this whenever touching models.py, alembic/versions/, 
or any database schema change.
---

# Database Migration Skill## When to Use

This skill activates when modifying database models or working with migrations.
## Key Rules
1. **Always use Alembic** - never modify schema manually
2. **Always backup first** - before running migrations
3. **Test downgrade** - verify migrations are reversible
4. **Use utcnow()** - never `datetime.now()` for timestamps

Full guide: `windsurf/docs/alembic_database_migration.md`

The elegant part is how this actually works under the hood. The AI agent only reads the skill definition — the name and description — and decides whether it’s relevant to the current task. It only loads the full content if it actually needs it. So your context window doesn’t get crowded with instructions that aren’t relevant to what you’re doing right now.

Think of it like a smart index. The agent knows what tools are available without having to load all of them at once. As your project grows and you accumulate more skills, this becomes genuinely important — otherwise you’d be stuffing the AI’s context with migration rules every time you’re just fixing a CSS bug.

Here are the official Windsurf docs URLs for each layer:

• Rules → https://docs.windsurf.com/windsurf/cascade/rules
• Skills → https://docs.windsurf.com/windsurf/cascade/skills
• Memories → https://docs.windsurf.com/windsurf/cascade/memories
• Workflows → https://docs.windsurf.com/windsurf/cascade/workflows

A word about the AI coding influencer wave

Social media is flooded right now with AI coding “experts.” Courses, threads, YouTube channels, LinkedIn carousels. And look — some of it helped me. I picked up a few useful tricks from people sharing their setups.

But the more I watched, the more I noticed a pattern: a lot of these people are selling more than building.

The content is about AI coding. The product is the course about AI coding. The proof of expertise is the follower count, not the shipped product.

It’s not unique to this space — it happens in every wave of new technology. Teaching scales better than building. Influence compounds faster than code. And there’s nothing inherently wrong with education and content creation.

But it gets worse. Increasingly, I suspect a lot of this content isn’t even written by the people selling it. No hands-on testing, no real projects behind it — just agents generating tutorials about how to use agents. The irony writes itself.

If you’re learning to build with AI, I’d encourage you to be a little selective about who you actually learn from. Look for people who are shipping things. Look for the GitHub links, the beta apps, the honest post-mortems. The people who are a little too busy building to post every day.

The best thing I did during my sabbatical wasn’t watching tutorials. It was opening Windsurf and starting to build something I actually cared about.

Finally

That’s where I am right now — three apps with users, a lot of lessons in my head, and genuinely more excited about building than I’ve been in years.

If you’re using iWish for an upcoming event, or want to try Guaxinim Finanças to get your finances under control, I’d love your feedback. And as always — questions, pushback, suggestions in the comments. That’s what makes writing these worth it.

(if you wanna follow my projects I’m adding all of them here -> https://guaxinimapps.pages.dev)

P.S. — A small heads-up on transparency: this post was written with AI assistance. The ideas, experiences, and opinions are entirely mine — I outlined the content, defined the structure, and wrote the core of each section. Claude helped me shape the language, improve the flow, and keep the tone consistent. Felt only right to mention it, given the topic.

After three months on sabbatical — studying, traveling, building things, and revisiting fundamentals — I felt it was worth writing down some of the lessons I picked up along the way.

This is not a guide, a manifesto, or a set of best practices.
It’s simply a collection of reflections from a period where I slowed down, went back to hands-on work, and tried to understand how modern AI tools actually fit into real systems and products.

Before talking about why I took a sabbatical, I want to start with the most practical thing I learned while building with LLMs every day:

Most problems with LLM-based systems are not only prompt problems — they’re architecture problems.

During this period, I built several small projects using LLMs as real system components — not demos. What consistently made the difference wasn’t clever prompting, but how the system around the LLM was designed.

Here are a few lessons that changed how I now think about building with LLMs.

Practical Lessons from Using LLMs Daily

Avoid the “Mega Prompt” Trap

One of the first mistakes I kept seeing (and making) was trying to encode everything into a single massive prompt.

In practice, it works much better to:

• split the flow into smaller, focused prompts,
• let each prompt solve one clear problem,
• and compose the results downstream.

Smaller prompts are easier to reason about, debug, and evolve over time.

Hybrid Flows Beat Prompt Fighting

In one project, the LLM kept producing a formatting error I explicitly asked it to avoid.
No matter how much I tweaked the prompt, the issue persisted.

The solution wasn’t better prompting.

Instead, I introduced a deterministic step:

• a simple function validated the output,
• and when the error appeared, a small “corrector prompt” fixed it.

This hybrid approach — classical logic plus LLMs — turned out to be far more reliable than relying on a single prompt to behave perfectly.

Evaluation and Prompt Versioning Matter

LLMs are still AI systems, which means they need evaluation, even when outputs are qualitative.

As Chip Huyen points out, having some evaluation strategy is essential.
Equally important is prompt management:

• Do you store prompts in a database?
• Do you version them in Git?
• How do you roll back a change that silently degraded quality?

These become real engineering problems surprisingly fast.

Meta-Prompting Is a Superpower

Instead of writing prompts from scratch, I started using LLMs to generate the first version of a prompt.

I’d describe the goal, ask for a draft, and then refine it.
This consistently surfaced assumptions and constraints I hadn’t considered.

Cost-Aware Orchestration Wins

Finally, cost matters more than most people expect.

A pattern that worked very well:

• use a state-of-the-art model for planning and design,
• produce a clear plan in Markdown,
• and pass that plan to a smaller, cheaper model for execution.

You keep most of the quality while drastically reducing cost.

Why I Decided to Dive Deep Again

I wanted to better understand LLMs, agents, and how they truly integrate into products and classical ML systems.

LLMs are everywhere right now. But in practice, I kept seeing the same patterns:

• LLMs being used where simpler systems would work better
• complexity added without a clear payoff
• impressive demos that don’t survive contact with production

So my goal during this sabbatical was simple:

Understand where LLMs actually shine, where they don’t, and how to combine them with traditional ML instead of replacing everything with a single model.

This exploration came from a mix of:

• structured courses,
• books,
• and, most importantly, building things end to end.

How LLMs Changed the Way I Code

With tools like Windsurf (and experiments with Devin), the feedback loop is dramatically shorter. Going from an idea to a working prototype can take minutes instead of days.

But there’s an important caveat:

LLMs don’t replace thinking.
They replace friction.

If you’re clear about what you want to build, LLMs multiply your productivity.
If you’re not, they just help you move faster in the wrong direction.

This reinforced something I had almost forgotten: strong fundamentals matter even more when you have powerful tools.

LLMs Don’t Replace Classical ML — They Complement It

One misconception I see often is the idea that LLMs will replace:

• recommendation systems
• ranking models
• search pipelines
• embeddings
• or even basic feature-based models

In practice, the opposite is true.

LLMs work best as orchestrators, not as a silver bullet.

Some observations from hands-on work:

• smaller, specialized models are still cheaper, faster, and more reliable for many tasks
• good embeddings + indexing often outperform a giant model
• RAG helps, but it’s not magic — bad data in still means bad output out

The most robust systems I’ve seen (and built) are hybrid by design.

Agents: Useful, but Not Everywhere

I spent some time studying agentic systems (including Andrew Ng’s Agentic AI course), and my takeaway is fairly pragmatic.

Agents are not “autonomous intelligence.”
They’re decision flows with memory and tools.

They work well when:

• tasks are long or repetitive
• multiple tools or APIs are involved
• partial autonomy is acceptable

They fail when:

• correctness must be absolute
• the domain is very constrained
• mistakes are expensive

The most useful question shifted from:

“How do I add an agent to this product?”

to:

“Which part of this product truly benefits from partial autonomy?”

Often, the honest answer is: none.

Revisiting the Fundamentals (Programming Matters)

Alongside LLM-focused work, I deliberately went back to fundamentals.

I’m currently halfway through a Deep Learning specialization with PyTorch, and that decision was intentional.

With LLMs writing code for us, it’s easy to:

• stop touching tensors
• forget how autograd really works
• treat models as black boxes

Writing PyTorch “by hand” again — layers, losses, backprop — was grounding.

It reminded me that:

• understanding what’s happening under the hood makes you a better engineer
• fundamentals give you intuition, not just answers
• LLMs are far more powerful when you know what you’re asking for

Building Small Projects Beats Reading Big Ideas

One recurring lesson: small projects teach faster than big theories.

During this period, I built personal tools end to end (including a finance tracker I previously wrote about). These projects forced me to deal with:

• trade-offs
• incomplete requirements
• architecture decisions
• and messy reality

LLMs made MVPs faster, but they didn’t remove responsibility.
You still have to decide what to build and why.

Returning to hands-on programming reignited a part of my motivation I didn’t realize I was missing.

Final Thoughts

The biggest takeaway from this sabbatical wasn’t technical.

It was this:

• tools change fast
• fundamentals change slowly
• good systems are still built, not prompted

LLMs are incredibly powerful, but they shine when combined with:

• solid engineering
• classical ML
• good data
• and clear product thinking

I plan to keep sharing what I learn as I go.

If you’re interested in following along:

• LinkedIn: https://www.linkedin.com/in/lfomendes/
• Medium: https://lfomendes.medium.com/

Thanks for reading.

Further Reading & Courses

If you’re interested in diving deeper into some of the topics I mentioned, these resources heavily influenced my thinking during this period:

📚 Books

• Designing Machine Learning Systems — Chip Huyen
  https://huyenchip.com/machine-learning-systems-design/
• AI Engineering — Chip Huyen
  https://huyenchip.com/ai-eng/

🎓 Courses

• Agentic AI — DeepLearning.AI (Andrew Ng)
  https://learn.deeplearning.ai/courses/agentic-ai/information
• PyTorch for Deep Learning (Professional Certificate) — DeepLearning.AI
  https://learn.deeplearning.ai/specializations/pytorch-for-deep-learning-professional-certificate/overview

Spreadsheet are very useful and you can do a lot of with them, but when you actually try to build something from scratch — a personal finance tracker, for example — you realize how quickly that power turns into pain.

It started innocently. I just wanted to organize my spendings — things like house expenses, dog costs, COFFEE, groceries, trips, supplements, and streaming subscriptions. A few categories, some monthly averages, maybe a chart or two. Simple, right?

Not really.

Within an hour, I was already buried under formulas, references, and endless cells. Each new feature (like recurring payments or monthly summaries) meant even more complexity. And every time I changed something, half of the sheet broke.

That’s when a thought hit me:

“It might actually be easier to code this than to make it on a spreadsheet.”

The AI-Programming Moment

I’ve been programming for more than 17 years, and lately I’ve been playing with AI-assisted development tools (“vibe coding”). You don’t have to write everything yourself anymore. You just describe what you want, iterate, and let the AI help you turn an idea into a working product.

So, instead of fixing broken formulas, I opened Windsurf IDE and decided to build my own finance tracker webapp.

In less than a day, I had something that looked (and worked) far better than any spreadsheet I’ve ever made. I could:

• Add expenses with categories and subcategories
• Track recurrent costs like rent or mortgage
• Visualize my spending with filters and charts
• Even upload my ugly PDF credit card statements and have the app extract and categorize everything automatically

It felt magical — not because of the features themselves, but because of how fast it came together.

The APP

The result was this: a clean, organized dashboard where I can finally see where my money goes without fighting with formulas.

The dashboard shows monthly summaries, spending trends, and category breakdowns. Each expense has a category, a subcategory, and optional recurrence, so I can easily distinguish between my monthly mortgage and one-time purchases.

There’s also a “spending by category” chart that makes it obvious where most of my budget goes — travel, home, food, streaming, education — and a recurrent cost tracker that automatically calculates my baseline monthly spending.

One of the most useful features, though, is the PDF reader. My credit card statement is a PDF nightmare — and if you’re a programmer, you know that parsing non-standardized PDFs is one of the worst tasks imaginable.

Now, I can just upload the file and let the AI do the heavy lifting: it extracts each transaction, parses the text, and adds the expenses automatically. I only need to categorize them, and they’re ready for analysis — no more copying and pasting from bank apps.

I even added a small flow to detect duplicate entries, using heuristics like matching amounts on the same day or similar descriptions.

And that’s the best part: adding new features like this is fast, easy, and dynamic.

Programming in the Age of AI

After building four different projects from scratch with AI assistance, I can say this with confidence: programming today feels completely different. It’s much faster — sometimes shockingly so — but it also demands a new way of thinking.

AI can accelerate everything, but it still needs guidance. That’s where experience comes in. My background in computer science and years of programming helped me understand when the AI was going in the wrong direction, or how to “unstick” it and guide it toward cleaner, more efficient code.

It might look easy — and in a sense, it is easier to start — but great results still depend on having the right mental models. You need to know when to ask for help, how to decompose problems, and how to review and refine the code that AI generates.

I’m also developing my own best practices for AI-assisted development — how to prompt, how to structure iterations, and how to balance control and creativity. I might write another post soon diving deeper into that, with concrete examples.

PS: This post was written by a human (me) but revised and refactored with an LLM.

Welcome back to my journey of building a web-based barista app powered by Genenrative AI! If you’re new here, this is the third part of a series where I’m blending my love for coffee with my professional side doing AI models.

In Part 1, I introduced the initial version of the app. The goal was to create a simple web interface using Streamlit that leverages the OpenAI API to assist coffee lovers in brewing the perfect cup. Users could either learn from scratch, improve their brew, or ask the app coffee-related questions. It was a fun MVP that used LLMs and gave a good enough result.

In Part 2, I addressed a key challenge: improving the accuracy of the app’s responses. I introduced a Retrieval-Augmented Generation (RAG) system to provide more reliable answers backed by curated content from coffee experts like James Hoffmann. By implementing RAG, the barista app could now fetch trustworthy information while still delivering engaging and helpful advice.

In this third part, I’ll walk you through several improvements: refining the prompts, enhancing the RAG system, and adding caching to make the app faster and more cost-effective.

If you’d like to explore the source code, you can find it here.

New version

While experimenting with version 2 of my Personal Barista, I identified several areas for improvement:

• Prompts
• Reliable Sources
• Document Representation
• RAG return
• Cache

Let’s dive into each of these changes.

Prompts

I restructured the prompts to follow a more effective format:

1. Task
2. Return Format
3. Warnings/Limitations
4. Context

Here’s an example of a new prompt format, where {context_str} comes from the RAG result:

Goal: Provide a clear, accurate, and helpful answer to a coffee-related question using both provided context and barista expertise.

Return Format:
    Your response should be structured as follows:
    1. Direct answer to the question (2-3 sentences)
    2. Supporting explanation with technical details (if relevant)
    3. Practical tips or recommendations (if applicable)
    4. References to specific sources from context (if available)

Warnings:
    - Stick to factual information from the context when available
    - Clearly distinguish between context-based information and general barista knowledge
    - Avoid speculation or unsupported claims
    - Keep the answer focused and relevant to the specific query

Context:
    ---------------------
    {context_str}
    ---------------------

Query: {query_str}
Answer:

Reliable Sources

In version 2, the barista’s knowledge base was limited. To improve this, I added a script that collects transcriptions from several trusted YouTube coffee influencers.

Running initialize_knowledge_base.py now fetches transcripts from 30 curated videos from each channel, processes the text, and creates embeddings for both individual chunks and summaries.

I’ve included four recommended channels in youtube_channels.json:

• jameshoffman
• europeancoffeetrip
• LanceHedrick
• morgandrinkscoffee

With this update, expanding the barista’s knowledge base is now fast and efficient — one script does it all!

Document Representation

Other thing that I missed while using the app was more information about each source.

I realized that adding more metadata could improve search quality. I now use an LLM to generate concise summaries and relevant tags for each document. This additional context helps the app identify the most relevant information more effectively.

Here is the prompt that I’ve used for that:

   prompt = f"""Given the following video title and transcript, please provide:
           1. A concise summary of the video content (max 200 words)
           2. 5 relevant tags that best represent the video's content

           Title: {title}
           Transcript: {text}

           Please format your response as follows:
           SUMMARY:
           [Your summary here]

          TAGS:
          - [tag1]
          - [tag2]
          - [tag3]
          - [tag4]
          - [tag5]"""

Not every task is ideally suited for an LLM, but they are very good at summarizing content and generating relevant tags from text.

Here’s an example of the updated format:

{
"title": "3 Essential Hario V60 Recipes: James Hoffmann, Tetsu Kasuya 
          & Osmotic Flow",
"source": "https://youtube.com/watch?v=P0mI6Ue8BKc",
"summary": "In this video, the hosts explore three different Hario V60 coffee brewing recipes developed by James Hoffmann, 
Tetsu Kasuya, and the osmotic flow method. Each method is explained in detail, 
including the grind size, pouring technique, and brewing time. 
The hosts demonstrate the step-by-step process for each recipe and 
taste and compare the results. The video emphasizes that there is 
no single best recipe for everyone, but these three techniques provide
 a solid foundation for creating a personalized V60 brewing method.",
"tags": [
    "Hario V60",
    "Coffee brewing",
    "James Hoffmann",
    "Tetsu Kasuya",
    "Osmotic flow method"
  ],
  "chunks": [
    "[Music] in this video we picked three hario v60 recipes that we believe give you a solid framework for improving your poor over coffee game we picked recipes developed by james hoffman tetsu kasuya and method called osmotic flow for each method we will give a little insight into its origin and main brewing approach then we will take you step by step through proving coffee using this recipe and at the end we will taste and compare different results unfortunately there is not a single best recipe the ultimate one that would work for everyone but we hope this video will help you to pick or create your favorite v60 method let's start with james hoffman's recipe he presented his ultimate v60 coffee technique back in 2019 i use it in different variations and came across this method in many coffee shops the brewing technique focuses on small number of pores and increase extraction by using finer grind size and increased agitation so let's try it let's prove james hoffman recipe first we will",
    "prepare our filter and wash it with hot or even boiling water if you have a plastic v60 it's not that important to have it hot but if you have ceramic v60 the boiling water is better because it gets your dripper heated properly okay we are gonna use 18 grams of coffee grind on commandante 21 clicks even the bed and now make a little well in the coffee grounds this is so the water gets absorbs faster and more evenly into the coffee now we can start we'll pour 45 grams of water usually james recommends to use two to three times the weight of the coffee and straight after pouring mix all coffee grounds until they are even don't worry to give it a proper stir and now we wait 45 seconds the pre-infusion phase is for all the co2 to escape the coffee so we can extract more flavors and it's especially important because now we have quite fine grind so it helps to escape faster now the first pour it's 60 of our total volume and that's up to 180 grams we should pour this in about 20 seconds this",
    "is for you to im......."]
}

RAG return

In the earlier version of my barista app, the RAG system retrieved text chunks from the knowledge base and used them directly as context in the prompt. While this approach worked reasonably well, I noticed some significant drawbacks during testing. For example, choosing two different incomplete recipes.

To address this, I introduced two key improvements:

1. Flexible Matching Options: I added a side menu in the app that allows users to choose between matching by chunks or summary.
2. Customizable Return Types: Users can now select whether they want the RAG system to return only the most relevant chunks or retrieve the whole document as context.

Using isolated chunks often led to incomplete or fragmented information. For example, when asking about AeroPress techniques, the app sometimes combined details from two separate recipes, resulting in an unclear or confusing response. Similarly, if key information appeared across multiple chunks, the app would fail to provide a complete answer.

I found that the most effective combination is: “whole file” and summary matching. But feel free to test different options.

You can easily test these settings in the “Search Coffee Knowledge” section of the app, where you can explore various results and navigate through the associated tags.

To illustrate the difference, here’s a comparison between chunk-based and summary-based retrieval for the AeroPress method explanation.

Cache

Since LLM requests are both time-consuming and costly, I added a Redis cache to improve performance.

For our barista the Redis cache is implemented before the context search — not just before the OpenAI call — maximizing efficiency. This was very easy using Windsurf, with two prompts and some code I had a Redis read to go saving my data.

Here it is an example of a key.

"guaxinim:{\"args\": {\"method\": \"V60\"}, 
\"func_name\": \"get_coffee_guide\", 
\"instance_attrs\": {\"similarity_field\": \"chunks\"},
 \"kwargs\": {\"rag_return_type\": \"chunks\"}}"

I’ve created a cache decorator that handles:

• Generates unique cache keys based on function names and arguments
• Serializes/deserializes data using pickle
• Sets a TTL (Time To Live) for entries

```python
@persistent_cache(ttl_days=30)
def get_coffee_guide(method: str) -> dict:
    # Your function implementation
    pass
```

I also added a Clear Cache button in the side menu to simplify testing and experimentation.

Lets make some coffee

Alright, enough with the text and code — let’s talk about what really matters: coffee! After all, this is supposed to be a barista app, not a Python tutorial.

Recently, my partner gave me an AeroPress GO for my birthday. Since I’d never used one before, I figured it was the perfect opportunity to put my improved barista to the test.

I fired up the app, selected “Learn to make perfect coffee”, chose AeroPress as the method, and set the RAG options to:

RAG Return: Whole file
Similarity Field: Summary

The result? A step-by-step guide, straight from trusted coffee experts, with clear instructions and helpful tips.

Since the AeroPress GO is smaller than the standard model, I had to tweak the recipe a bit. After some quick math (and resisting the urge to just wing it), I settled on 12.5g of coffee with 200ml of water.

And the result? Delicious! Smooth, rich, and full of flavor.

The AeroPress seemed a bit intimidating at first, but it turns out it’s fast, easy to clean, and surprisingly versatile. I have a feeling this little gadget is going to become my go-to brewing method.

Conclusion

With these new improvements, my Racoon barista app has come a long way — and I’m pretty happy with where it stands now. The refined prompts, expanded knowledge base, improved RAG system, and caching have made it faster, smarter, and much more reliable.

This project started as a fun way to combine my love for coffee with my AI expertise, and it turned out to be an incredible learning experience. While I’m sure there’s always room for more tweaks and enhancements, I’m satisfied with the current state of the app.

Now that my caffeinated creation is brewing great results, I’m thinking about starting a new side project — this time inspired by another one of my passions: movies. I’m still brainstorming ideas, but who knows? Maybe my next post will feature a recommendation system that helps you pick the perfect film for your next movie night.

Until then, thanks for following along on this journey! If you have any suggestions, questions, or just want to chat about coffee (or movies), feel free to reach out.

Part 1: The beginning with generative AI
https://lfomendes.medium.com/using-openai-api-to-make-a-coffee-barista-part-1-9ea500c90d77

Part 2: Raccoon learns RAG to improve accuracy
https://lfomendes.medium.com/using-openai-api-to-make-a-coffee-barista-part-2-now-using-rag-73ef598aa0f8

Code available in: https://github.com/lfomendes/guaxinim-barista

Hello everyone!

This is the second part of my personal project of creating a personal barista to help coffee lovers to make the best cup of coffee possible. The first part can be seen here.

In the first part we created a simples coffee barista that can help you improve you coffee cup and respond to coffee related questions. Now I’m going to show how we can incorporate RAG to help the barista make fewer errors and provide reliable sources.

What is RAG and why use one?

I asked ChatGPT for help with my acidic coffee problem on two different days, and I got two completely different answers! One day, it suggested making the grind more fine, and the next time, it told me to go coarser. This is what we call AI “hallucination” — when the model comes up with stuff that isn’t exactly true. Both sounded plausible, but I consulted my most trusted coffee specialist (James Hoffman) and found this post.

A coarser grind means less surface area is exposed to water during brewing, resulting in lower acid extraction. Try going one notch coarser than you normally would for maximum smoothness. Just be aware that coarser grinds can also impact overall extraction, so experiment to strike the right balance.

And that’s where Retrieval-Augmented Generation (RAG) comes in handy in AI. RAG helps make AI responses more accurate by data while generating answers. In the context of the personal barista app, this means it’s not just making stuff up — it’s pulling actual, relevant coffee info to help you get the best brew, every time. With RAG, the app offers solid coffee advice that’s both creative and well-grounded.

Creating a simple RAG

To address the problem of varying or incorrect answers, we incorporate RAG into our barista application.

RAG systems can be very complex with databases, many jobs and steps. For our coffee barista V2.0.0 I decided to start simple. So these were my tasks for this version.

• Gather documents from reliable sources
• Write a script that divides these documents into chunks. (pieces)
• Create text embeddings for each chunk and save them in a JSON file.
• During the app loading get this json file and put these embeddings into a Fasttext so we can do similarity search.
• Create embeddings from the user queries and use a similarity search to get the most similar chunks from these documents
• Change the prompt so it take these chunks into consideration while responding to the user
• Add the sources into the interface

Documents

Since this is the first version of our RAG, I downloaded three PDFs from the James Hoffman blog.

• HowtoBrewLessAcidicCoffee.pdf
• How to Make Tiramisu Coffee.pdf
• How Many Grams of Coffee for Cappuccino.pdf

We are just creating a MVP, if it works for these 3 we can incorporate more curated data afterwards easily.

Code

For the PDF processing, I created the processor.py script, which divides the texts into chunks, creates embeddings, and saves them into a JSON file.

To create the embeddings I used the Sentence Transformer since it is easy to use and have a good enough quality for this task. We load all-MiniLM-L6-v2, which is a MiniLM model finetuned on a large dataset of over 1 billion training pairs.

Our model is intended to be used as a sentence and short paragraph encoder. Given an input text, it outputs a vector which captures the semantic information. The sentence vector may be used for information retrieval, clustering or sentence similarity tasks.

def create_embeddings(chunks: List[str], model_name: str = 'all-MiniLM-L6-v2') -> List[List[float]]:
    """
    Create embeddings for a list of text chunks using sentence-transformers.
    
    Args:
        chunks (List[str]): List of text chunks to create embeddings for
        model_name (str): Name of the sentence-transformers model to use
        
    Returns:
        List[List[float]]: List of embeddings for each chunk
    """
    model = SentenceTransformer(model_name)
    embeddings = model.encode(chunks, show_progress_bar=True)
    # Convert numpy arrays to lists for JSON serialization
    return embeddings.tolist()

And I changed all prompts to take the information into consideration

    CONTEXT_PROMPT_TEMPLATE = 
    """Context information is below.
    ---------------------
    {context_str}
    ---------------------
    Given the context information and your expertise as a professional barista,
    provide a answer to the query.
    Query: {query_str}
    Answer: """

With this we can see an answer from the barista citing the sources.

I also created a new section of the app so we can debug this similarity search. This new screen has a text input and it returns the chunks and titles with their similarity score. In the two images below you can check a good match and a bad match as example.

In this first example the input is about coffee and desserts. From the documents that we have, what we would expect is that the the chunks from the “How to Make Tiramisu Coffee” would be the most similar and it seems that our search return 3 chunks from this blog post. Great!

Now, for the second test I used a non-coffee relate question and we can see that the similarity scores are close to zero and one of them is even negative.

App flow

Now our barista app have two different flow, one that is offline. That is, we can run it only once to process all pdfs from a folder and save a json file.

And a second flow that will load this json into the Fasttext, use this fasttext to do a similarity search for the chunks of information and incorporate them into the prompt.

Results

And here is a video of this new version of the app:

Now we can have a little more trust in our Barista, since he is studying from curated sources.

Nexts steps

Our Raccoon Barista is well on its way to becoming a reliable coffee companion. It now knows how to gather valuable information and respond to user queries, citing all sources used for transparency.

For the V3.0.0 I am planning to expand its information database and enhance interactivity, allowing users to engage in more dynamic conversations with the barista. I’m also considering writing a post on evaluating the quality of the barista’s answers.

I’d love to hear your thoughts on what additional features or improvements you’d like to see in our barista. Your suggestions are most welcome!

Until the next one!

The third part is out

https://lfomendes.medium.com/using-openai-api-to-make-a-coffee-barista-part-3-d5bc7cb8a203

Code available in: https://github.com/lfomendes/guaxinim-barista

Like many other geeks I’ve been getting into the specialty coffee scene. It’s been an exciting and caffeine-fueled journey! Brewing a great cup is simple to start but tricky to master.

I decided to blend my love for coffee with my interest in new technologies and tools.

My idea is to create a web app that uses LLMs (genAI) to help people brew better coffee while allowing me to experiment with new tools and APIs. I’ll share the code publicly and post insights in parts on Medium.

In this first installment, I’ll be building the app using Streamlit, the OpenAI API, and the Windsurf IDE. I know it might have some issues like occasional hallucinations and a “not-so-polished” interface. My apologies to all designers out there!

For those not familiar with Portuguese, ‘guaxinim’ (pronounced gwa-shee-neem) means raccoon. Why raccoons? They’re adorable, have human-like hands, and just might dream of crafting the perfect brew themselves!

So follow me in this caffeinated journey

The MVP

Let’s dive into the fun part: here’s the interface we’ve created so far.

And a video of the app in action

I think it is a good enough MVP with all the necessary capabilities and it took me only some hours to create with these new tools.

The code

The flow of the app is easy, the person chooses an action from

• Teach me how to brew from zero
• Help me improve my brew
• Ask anything coffee related to the web-barista

Each action will show a different interface below but all of them will call an OpenAI api using its chat completion command.

For this mvp my folder is organized like this

guaxinim/
├── guaxinim/
│   ├── __init__.py
│   ├── core/
│   │   ├── __init__.py
│   │   ├── guaxinim_bot.py
│   │   └── coffee_data.py
│   ├── ui/
│   │   ├── __init__.py
│   │   └── home.py
│   └── utils/
│       └── __init__.py
├── tests/
│   └── unit/
├── main.py
├── README.md
├── requirements.txt
├── .gitignore
└── env.example

The Streamlit makes it easy to build an interface with only python code, almost everything for the interface is inside the home.py file.

Everything will be written in python using the windsurf IDE, I will try to use it as planned with some propts like this

Analyze all .py files and suggest possible unit tests, create the necessary 
folders and organize the files accordingly

Just so you understand that was the result for this prompt at the time

Prompts and OpenAI api

I created 3 different prompts, one for each action, they can be found on the guaxinim_bot.py file. I’m using the chat completions from Open AI.

Improve prompt

system
You are a professional coffee barista expert.
user
Analyze these coffee parameters and suggest improvements: Issue: 
Too acidic Coffee amount: 20.0g Water amount: 180.0ml 

Improve prompt

You are a professional coffee barista with years of experience.
You are teaching someone how to make an excellent cup of coffee using 
the Cold Brew method. Please provide a detailed, step-by-step guide that 
includes: 1. Required equipment 2. Recommended coffee-to-water ratio 3.
Grind size recommendation 4. Water temperature 5. Detailed brewing steps 
6. Common mistakes to avoid 7. Tips for achieving the best results 
Format your response in markdown for better readability.

Coffee question prompt

system
You are a professional coffee barista expert.
user
Check if the following question is coffee-related: 
If yes: Provide a detailed answer 
If no: Reply with 'I only answer questions about coffee.' 
Question: What is the best place to buy coffee?

I’ve added a basic security feature to ensure the barista only answers coffee-related questions. I’ve tried to “hack” this but it seems that this protection is good enough for now.

Using OpenAI API is very straightforward, as demonstrated by the following code snippet:

try:
    response = self.client.chat.completions.create(
        model=self.GPT_MODEL,
        messages=[
            {
                "role": "system",
                "content": "You are a professional coffee barista expert.",
            },
            {"role": "user", "content": basic_prompt + query},
        ],
        temperature=0.2,
        max_tokens=500,
        store=True,
    )
    return response.choices[0].message.content
except (APIError, APIConnectionError) as e:
    return f"Error processing question: {str(e)}"

You can check the documentation for chat completion here. I’m using 0.2 temperature to make it more focused and deterministic.

Next Steps

I’m very happy with the current state of this first version. It is available in the tag v1.0.0 (git checkout v1.0.0) in the git repository.

But now I want to take it to the next level by collecting some curated information about coffee from experts like James Hoffman and improve the barista to use this knowledge and even point the user to the source of information.

This is usually what Retrieval-Augmented Generation (RAG) is used for, so in the next post I will share my experience creating a simple RAG for this barista APP.

Thanks for reading! Feel free to leave any questions or suggestions in the comments.

The second part is already out

https://lfomendes.medium.com/using-openai-api-to-make-a-coffee-barista-part-2-now-using-rag-73ef598aa0f8

The third part

https://lfomendes.medium.com/using-openai-api-to-make-a-coffee-barista-part-3-d5bc7cb8a203

This year, I decided to start writing and sharing knowledge about Data Science. My goal wasn’t to become an influencer on LinkedIn/Medium, but rather to motivate myself to read more and think deeply about the content. Writing, even if just a simple summary, helps reinforce learning (pun not intended).

For those who missed it, here is a list of posts I published throughout the year:

Weekly Reading: AI Agents: A post where I discuss the popular topic of AI agents.

Weekly Reading: Meta’s Approach to Machine Learning Prediction Robustness: A brief post highlighting Meta’s material on robustness in machine learning models, a topic also debated at iFood.

Designing a Machine Learning System: A discussion about how an AI model is merely a part of a larger system, inspired by an excellent post by Chip Huyen.

Recommended Reading: How I Use “AI”: Discussing the role of genAI in professional productivity, based on tips from the author Nicholas Carlini.

Transforming Data into Art: The Evolution of Cover Selection at Netflix: My favorite post of the year, combining my passion for movies, series, and AI. It was meant to be just a post on Causal Machine Learning and turned into an exploration of Netflix’s evolution in choosing covers/artwork.

Thoughts on: RAG, Hybrid Search, and Rank Fusion: Reflections on important topics for my professional practice, such as RAG and Rank Fusion.

Conclusion

There were only a few posts, but I enjoyed the process of writing them. I’m not a writer, but these activities helped me read and reflect more on each topic. I hope they were helpful to others as well.

Stay tuned, in 2025 there will be more!