DEV Community: Jefri Bulo'

PuskesmasAI: Finishing an Offline AI Triage App for Rural Indonesia

Jefri Bulo' — Fri, 12 Jun 2026 02:23:35 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

PuskesmasAI is an offline-first Progressive Web App (PWA) that brings AI-powered medical triage to community health workers (kader) in rural Indonesia — no internet connection required after the first setup.

Indonesia has 1 doctor per 5,000 people, far below the WHO's recommended 1:600 ratio. In remote 3T regions (Tertinggal, Terdepan, Terluar — Underdeveloped, Frontier, and Outermost), over 45% of community health posts lack adequate medical staff. The kader — non-medical volunteers who are often the only frontline health resource for millions — must make triage decisions without doctors nearby, without structured guidance, and frequently without internet.

PuskesmasAI solves this. A kader inputs patient symptoms via a simple form in Bahasa Indonesia, and the app returns a structured AI triage result: GREEN / YELLOW / ORANGE / RED — with recommended actions, possible conditions, red flags, and an auto-generated referral note. Patient records are stored locally in IndexedDB and sync to the Puskesmas dashboard when connectivity returns.

Built with Next.js 14 (PWA) + Tailwind CSS on the frontend, Python Flask on the backend, and Gemma 4 E4B (GGUF quantized via Ollama) as the on-device AI model (~2.5GB, zero cloud dependency). Zero patient data ever leaves the community — privacy by design.

This project means a lot to me personally. I'm based in Makassar, South Sulawesi — and the health disparity between urban and rural Indonesia is something I witness firsthand. PuskesmasAI is my attempt to put AI where it's needed most.

Demo

🔗 Repository: https://github.com/jefribulomakassar/gemma4_good_hackathon

⚠️ Local-first by design. PuskesmasAI runs entirely on-device — the Next.js frontend (port 3000) and Python Flask backend (port 5000) are started separately on a local machine, with Gemma 4 E4B served via Ollama. There is no hosted demo because the whole point is offline operation: no cloud, no data leaving the device.

To run locally:

# Terminal 1 — Backend
cd backend && pip install -r requirements.txt
ollama run gemma4:e4b
python app.py  # runs on :5000

# Terminal 2 — Frontend
cd frontend && npm install
npm run dev  # runs on :3000

Demo scenario:

Phone in airplane mode → open PuskesmasAI → fill triage: 32-year-old female, symptoms: "fever for 3 days, red spots on skin, nausea" → tap Analyze → result: 🟠 ORANGE with action list and referral note → turn WiFi on → patient record auto-syncs to dashboard.

The Comeback Story

This project originally started as my submission for the Kaggle × Google DeepMind Gemma 4 Good Hackathon (Health & Sciences track, deadline: May 18, 2026). I had the full concept, the README, the architecture diagram, and the backend security layers ready — but I ran out of time before finishing the core data files and frontend components that would make the app actually work.

Before (what existed at the original deadline):

✅ Full README with architecture and problem statement
✅ Backend Flask app with 6 security layers (JWT, HMAC, rate limiting, CORS, prompt injection guard, privacy-safe logging)
✅ Frontend structure with Next.js PWA config
✅ TriageResult.tsx, OfflineBanner.tsx, VoiceInput.tsx components
❌ No medical_kb.json — the AI had no medical knowledge base
❌ No symptom_map.json — no symptom-to-condition mapping
❌ No drug_reference.json — no drug dosage reference for kaders
❌ No SymptomForm.tsx — the main input form was missing
❌ No db.ts / sync.ts — offline storage and sync not implemented

After (what was added during the Finish-Up-A-Thon):

✅ backend/data/medical_kb.json — offline medical knowledge base covering the 10 most prevalent diseases in rural Indonesia (Dengue/DBD, Typhoid, Malaria, ARI/ISPA, Diarrhea, Hypertension, Tuberculosis, Malnutrition, Cholera, Pre-eclampsia) with symptoms, red flags, triage levels, and actions — all in Bahasa Indonesia
✅ backend/data/symptom_map.json — 32 symptom groups with Indonesian colloquial keywords, probability weights, and automatic triage escalation rules
✅ backend/data/drug_reference.json — 10 essential Puskesmas drugs with pediatric dosing per kg body weight, contraindications, and kader-safe drug classification based on Indonesia's National Formulary (Formularium Nasional)
✅ frontend/src/components/SymptomForm.tsx — mobile-first patient intake form with symptom shortcut buttons, automatic pregnancy detection, temperature indicator, and form validation
✅ frontend/src/lib/db.ts — IndexedDB wrapper using Dexie.js for offline patient record storage
✅ frontend/src/lib/sync.ts — auto-sync module that uploads pending records to Turso cloud when connectivity returns

The transformation: from a well-documented skeleton to a genuinely functional offline AI triage tool.

My Experience with GitHub Copilot

GitHub Copilot was central to finishing this project — especially for the data-heavy and boilerplate-heavy files that would have taken hours to write manually.

symptom_map.json and drug_reference.json were generated entirely using GitHub Copilot in the github.dev editor — no local setup needed. I simply pressed . on the repository page to open github.dev, then used Ctrl+I to invoke inline prompts. I provided the full file path, the data structure requirements, and domain-specific context (Indonesian rural health context, Formularium Nasional constraints). The results were accurate, well-structured, and included details I hadn't explicitly specified — like colloquial Bahasa Indonesia symptom terms ("step" for kejang/seizure, "ngos-ngosan" for rapid breathing) and the appropriate kader-safe drug classification tiers.

db.ts and sync.ts were scaffolded by Copilot with idiomatic TypeScript and Dexie.js patterns that matched the existing codebase — including the synced boolean field for tracking upload status and the navigator.onLine check in the sync logic. What would have been an hour of boilerplate became a focused 10-minute review and refinement session.

What I learned: Copilot works best when you give it full context — the exact file path in the repo, the purpose of the file, the related files it should be aware of, and the domain-specific constraints. A well-crafted prompt saved me hours on each file.

"The best AI is not the most complex one. It's the one that works for the people who need it most — even when the internet doesn't."

PuskesmasAI: Finishing an Offline AI Triage App for Rural Indonesia

Jefri Bulo' — Sun, 07 Jun 2026 12:14:44 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Demo

🔗 Repository: https://github.com/jefribulomakassar/gemma4_good_hackathon

⚠️ Local-first by design. PuskesmasAI runs entirely on-device — the Next.js frontend (port 3000) and Python Flask backend (port 5000) are started separately on a local machine, with Gemma 4 E4B served via Ollama. There is no hosted demo because the whole point is offline operation: no cloud, no data leaving the device.

To run locally:

# Terminal 1 — Backend
cd backend && pip install -r requirements.txt
ollama run gemma4:e4b
python app.py  # runs on :5000

# Terminal 2 — Frontend
cd frontend && npm install
npm run dev  # runs on :3000

Demo scenario:

Phone in airplane mode → open PuskesmasAI → fill triage: 32-year-old female, symptoms: "fever for 3 days, red spots on skin, nausea" → tap Analyze → result: 🟠 ORANGE with action list and referral note → turn WiFi on → patient record auto-syncs to dashboard.

The Comeback Story

Before (what existed at the original deadline):

✅ Full README with architecture and problem statement
✅ Backend Flask app with 6 security layers (JWT, HMAC, rate limiting, CORS, prompt injection guard, privacy-safe logging)
✅ Frontend structure with Next.js PWA config
✅ TriageResult.tsx, OfflineBanner.tsx, VoiceInput.tsx components
❌ No medical_kb.json — the AI had no medical knowledge base
❌ No symptom_map.json — no symptom-to-condition mapping
❌ No drug_reference.json — no drug dosage reference for kaders
❌ No SymptomForm.tsx — the main input form was missing
❌ No db.ts / sync.ts — offline storage and sync not implemented

After (what was added during the Finish-Up-A-Thon):

✅ backend/data/medical_kb.json — offline medical knowledge base covering the 10 most prevalent diseases in rural Indonesia (Dengue/DBD, Typhoid, Malaria, ARI/ISPA, Diarrhea, Hypertension, Tuberculosis, Malnutrition, Cholera, Pre-eclampsia) with symptoms, red flags, triage levels, and actions — all in Bahasa Indonesia
✅ backend/data/symptom_map.json — 32 symptom groups with Indonesian colloquial keywords, probability weights, and automatic triage escalation rules
✅ backend/data/drug_reference.json — 10 essential Puskesmas drugs with pediatric dosing per kg body weight, contraindications, and kader-safe drug classification based on Indonesia's National Formulary (Formularium Nasional)
✅ frontend/src/components/SymptomForm.tsx — mobile-first patient intake form with symptom shortcut buttons, automatic pregnancy detection, temperature indicator, and form validation
✅ frontend/src/lib/db.ts — IndexedDB wrapper using Dexie.js for offline patient record storage
✅ frontend/src/lib/sync.ts — auto-sync module that uploads pending records to Turso cloud when connectivity returns

The transformation: from a well-documented skeleton to a genuinely functional offline AI triage tool.

My Experience with GitHub Copilot

GitHub Copilot was central to finishing this project — especially for the data-heavy and boilerplate-heavy files that would have taken hours to write manually.

"The best AI is not the most complex one. It's the one that works for the people who need it most — even when the internet doesn't."

Google I/O 2026: We're Not Building Apps Anymore — We're Deploying Agents

Jefri Bulo' — Sat, 23 May 2026 08:44:52 +0000

Google I/O 2026: We're Not Building Apps Anymore — We're Deploying Agents

This is a submission for the Google I/O Writing Challenge

Let me be honest: I almost skipped this year's keynote.

After a few years of "AI-powered everything" announcements that turned out to be half-baked demos, I'd gotten a little cynical. You know the cycle — big stage, polished slides, features that show up six months late and with half the functionality.

But I watched anyway. And somewhere around the Developer Keynote, something clicked.

This wasn't just another update cycle. Google wasn't adding AI to their products. They were replacing the foundation underneath them.

The Phrase That Actually Matters

Sundar Pichai opened with "the agentic Gemini era." Easy to brush off as marketing speak. I almost did.

But then I watched the Firebase session. Then Flutter. Then Google AI. And I realized — every single team was building toward the same thing from a different direction. That doesn't happen by accident. When a company that size tells a coherent story across every product at once, they're not pitching a feature. They're announcing a direction they've already committed to.

So what's the actual direction? Here's how I'd put it in plain terms:

Google wants the gap between "I have an idea" and "there's a deployed app" to be measured in hours, not sprints.

What Actually Shipped (That You Should Care About)

Antigravity 2.0 — The Part Everyone Will Miss at First

Antigravity is Google's agent-first dev platform, and version 2.0 is a big jump. You can now spin up specialized subagents to tackle different parts of a complex workflow. There's a new CLI. And — this is the part that caught my attention — Managed Agents in the Gemini API means a single API call gives you a fully provisioned agent with a remote sandbox. No infrastructure setup. No config files. Just call it.

They also launched the Antigravity SDK so you can deploy the agent harness on your own infrastructure with full programmatic control. Plus Google AI Studio now has one-click deploy to Cloud Run and native Kotlin support. Build, deploy, ship — all without leaving one interface.

I'll be honest: it sounds too smooth. Production always has edges that demos don't. But the direction is real, and the pieces are actually there now.

Firebase — Quietly Doing a Lot

Firebase had maybe the most interesting session if you build mobile or full-stack apps.

Agent Skills now cover Android, iOS, and Flutter — not just Web. This matters because the difference between a coding agent that knows "Firebase" generically and one that knows Firebase in the context of Flutter's widget lifecycle is enormous. One gives you boilerplate. The other gives you something that actually fits.

They also shipped Firestore native full-text search in preview. No more syncing to Algolia or Elasticsearch. Just Firestore. That's a feature people have been asking for literally for years.

And then there's this: Firebase Studio is shutting down in 2027. New workspace creation closes June 22, 2026. The migration path is Google Antigravity. If you're using Firebase Studio today, plan accordingly. Core Firebase services (Firestore, Auth, App Hosting, etc.) are all fine — this is just the IDE story consolidating.

Flutter 3.44 — Bigger Than It Sounds

Flutter releases can sometimes feel like polish without substance. This one felt different.

Agentic hot reload is here — AI agents can now manipulate your UI code and see changes live. The Flutter GenUI SDK and A2UI protocol let models dynamically generate and adapt UIs based on user intent. Genkit Dart launched as an open-source framework for full-stack AI-powered Flutter/Dart apps, supporting Anthropic, OpenAI, and Google models with the same code across backend and frontend.

Also: Flutter now runs in the 2026 Toyota RAV4 infotainment system. LG's webOS SDK is coming. Material and Cupertino libraries are being decoupled into standalone packages with their own versioning. That last one is subtle but matters a lot for teams doing heavy design customization.

Dart 3.12 also shipped with experimental Dart support for Firebase Cloud Functions — meaning true full-stack Dart is becoming genuinely practical now, not just theoretically possible.

Gemini 3.5 Flash + WebMCP + SynthID

Gemini 3.5 Flash launched as the first model in Google's new series explicitly built for action, not just reasoning. It outperforms Gemini 3.1 Pro on agentic benchmarks while keeping Flash-level speeds. Token processing across Google products hit 3.2 quadrillion per month — sevenfold year-over-year growth. 8.5 million developers on Gemini now.

WebMCP is a proposed open web standard that lets browser-based AI agents execute against JavaScript functions and HTML forms with precision. Origin trial starts in Chrome 149. If this gets traction, it's a big deal for web automation and agentic workflows in the browser.

SynthID — Google's AI content watermarking — now has OpenAI, Kakao, and Eleven Labs adopting it. Cross-industry watermarking starting to look like an actual standard, not just a Google feature.

My Honest Read on All of This

Here's what I keep coming back to: Google isn't just shipping tools. They're reshaping what the job actually is.

The Android Migration Agent previewed this year can take a React Native or iOS app and migrate it to native Kotlin — work that previously took weeks, now taking hours. Chrome DevTools for Agents lets AI automate quality audits and debug in real time without manual oversight. Modern Web Guidance gives coding agents a curated set of expert-vetted skills for building performant, accessible web apps.

The consistent pattern: things that used to require a developer to do are being handed to agents. The developer's job shifts to deciding what to build and whether the output is right.

That's either exciting or unsettling depending on your position. Probably both.

The Part Google Didn't Say

Here's the honest gap in everything I watched:

None of it addressed what happens when agents get it wrong at scale. The demos were clean. Production is not clean. An agent with Crashlytics access and autonomous debugging capabilities is powerful. It's also capable of confidently making the wrong fix to the wrong problem and deploying it.

The framework is maturing fast. The guardrails are still catching up.

So What Does This Mean for Us?

I don't think this signals the end of software development. I think it signals the end of a specific version of it — where the bottleneck is writing code.

The new bottleneck is knowing what to build. Having the judgment to review what an agent produced and catch what's subtly wrong. Understanding enough about the underlying systems that you're not just a prompt engineer hoping things hold together in prod.

That's not a smaller job. It's a different one.

Google I/O 2026 was the clearest signal yet that the transition is happening whether we're ready or not. The question isn't whether to adapt — it's how fast, and toward what.

I'm still figuring that out. But at least now I'm not skipping the keynotes.

Tags: #googleiochallenge #devchallenge #ai #webdev

Conversa — A Multi-Agent AI Platform Powered by Gemma 4

Jefri Bulo' — Sat, 23 May 2026 08:04:33 +0000

Conversa — A Multi-Agent AI Platform Powered by Gemma 4

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Conversa is a multi-agent AI platform built with Next.js (App Router) that transforms unstructured files — audio recordings, documents, and images — into structured, actionable intelligence. The platform consists of three specialized agents, each solving a distinct real-world problem:

🎙️ Meeting Analyzer (Audio Agent)

Upload a voice recording (MP3, WAV, M4A) and get back:

A full verbatim transcript via Groq Whisper
Key discussion points extracted by Gemma 4
Action items with clear ownership
Follow-up questions to keep the conversation moving

For large audio files (>25MB), the agent automatically compresses them in the browser — resampling to 16kHz mono WAV using the Web Audio API — before sending to the server.

📄 Brief Generator (Document Agent)

Upload a PDF or Word document and choose from 5 brief types:

Meeting Brief — agenda, discussion points, critical questions
Project Kickoff — goals, scope, roles, milestones
Client Proposal — executive summary, pricing overview
Interview Prep — questions, scorecard, red flags
SOP Generator — step-by-step procedures and checkpoints

Gemma 4's 256K context window processes the entire document in one pass — no chunking, no information loss. Word documents (.docx/.doc) are automatically converted to PDF via mammoth + jsPDF before processing.

🖼️ Whiteboard Analyzer (Image Agent)

Upload a whiteboard photo or handwritten notes (JPG, PNG, WEBP) and receive:

Extracted text — every visible word, transcribed verbatim
Diagram & visual element descriptions — shapes, flows, connections
Structured summary — professional 2–4 sentence synthesis
Suggested next steps — 3–5 actionable recommendations

Images above 4MB are automatically compressed via Canvas API before upload to stay within Vercel's serverless function payload limit.

All three agents stream results progressively via Server-Sent Events (SSE), so content appears section by section as Gemma 4 generates it — no waiting for the full response.

Demo

🌐 Live App: https://conversa-gemma4.vercel.app

Try uploading a meeting recording, a PDF report, or a whiteboard photo to see all three agents in action.

Code

📦 GitHub Repository: https://github.com/jefribulomakassar/conversa-gemma4

Tech stack:

Framework: Next.js 14 (App Router, TypeScript)
AI Model: google/gemma-4-26b-a4b-it via OpenRouter
Transcription: Groq Whisper (audio pipeline)
Deployment: Vercel
Styling: Pure CSS-in-JS (no UI library)

Key files:

app/
├── api/
│   ├── audio/route.ts      → Transcription + Gemma 4 analysis pipeline
│   ├── document/route.ts   → PDF extraction + brief generation pipeline
│   └── image/route.ts      → Base64 encoding + visual analysis pipeline
├── audio/page.tsx          → Meeting Analyzer UI
├── document/page.tsx       → Brief Generator UI
└── image/page.tsx          → Whiteboard Analyzer UI

How I Used Gemma 4

Model Choice: `google/gemma-4-26b-a4b-it` (26B MoE)

I chose Gemma 4 26B (the 26-billion parameter Mixture-of-Experts variant, a4b architecture) for three specific reasons:

1. Multimodal capability for the Image Agent
The image agent sends photos directly as base64 image_url to the model. Gemma 4's native vision support eliminates the need for a separate OCR service — the same model that generates structured summaries also reads handwritten text and interprets diagram flows.

2. 256K context window for the Document Agent
Most open models force chunking for long documents, which causes information loss at chunk boundaries. Gemma 4's extended context lets the document agent ingest entire PDFs (legal contracts, project proposals, SOPs) in a single API call and reason over the full content holistically.

3. Structured JSON output reliability
All three agents require the model to return strict JSON (no markdown fences, no preamble). Gemma 4 26B consistently honors the system prompt instruction "respond with ONLY a valid JSON object" with temperature 0.2, which made the SSE streaming pipeline reliable without complex retry logic.

Pipeline Architecture

Each agent follows the same SSE streaming pattern:

Client uploads file
      ↓
Browser-side compression (if needed)
      ↓
POST /api/[agent] (FormData)
      ↓
Server: parse → convert → call Gemma 4 via OpenRouter
      ↓
Stream SSE events back: status → field1 → field2 → done
      ↓
Client renders results progressively

The model is called with temperature: 0.2 and max_tokens: 3000 across all agents to balance creativity with output consistency.

For the audio agent, Gemma 4 receives the transcript text (produced by Groq Whisper) and extracts key points, action items, and follow-up questions — acting as a reasoning layer on top of the raw transcription.

For the document agent, the PDF is converted to base64 and passed in full to Gemma 4, which then generates structured brief sections streamed one by one as SSE section events.

For the image agent, the photo is passed as a image_url content block alongside a detailed JSON schema prompt, and Gemma 4 returns all four analysis fields in a single structured response.

AI Demystified: What I Learned from IBM Dev Day

Jefri Bulo' — Wed, 01 Apr 2026 07:42:44 +0000

AI Demystified: What I Learned from IBM Dev Day

Recently, I completed IBM Dev Day: AI Demystified (February 25).

What stood out to me is that it wasn’t just about “what AI is,” but more about how to think behind AI systems themselves.

As a developer, it reminded me that understanding fundamentals matters more than simply using tools.

Still a long journey ahead, but I’m glad to keep learning and growing step by step.

Certificate of participation for completing IBM Dev Day: AI Demystified — a small milestone in my AI learning journey.

AI #IBMDevDay #DeveloperJourney

From Data to Insight: Turning Spreadsheets into Visual Understanding

Jefri Bulo' — Mon, 05 Jan 2026 07:51:15 +0000

What I Built

I built a web-based tool that helps users understand their data by turning raw spreadsheet files into clear visual summaries.

The tool accepts data from both local Excel files and Google Sheets. Many people already have data stored in spreadsheets, but reading and interpreting that data is often harder than expected—especially for non-technical users. Rows and columns alone rarely tell a story.

This project focuses on solving that problem.

Instead of asking users to manually analyze tables or design charts from scratch, the application automatically processes the structure of the data and presents it through visualizations, tables, and concise summaries inside a web interface. The goal is to help users quickly grasp what their data is saying.

Users can upload or select their data, and the system will:

Analyze the data structure
Detect patterns such as numeric, categorical, and time-based fields
Map the data into appropriate visual representations
Present the results in a clean, easy-to-read web UI

The visual output stays live and updates automatically when the underlying data changes.

To support users from different regions, the interface also includes multi-language support. At the moment, several languages are available, with more planned as the system evolves.

This tool is designed for a broad range of users—from beginners who are new to data analysis, to business users and organizations that need fast insights without relying on complex BI tools.

Demo & Testing Access

The public web testing link is currently being configured and will be shared soon.

In the meantime, the pitch video below demonstrates the full workflow and core functionality of the application, including data ingestion, analysis, and visualization output.

My Pitch Video

Here is the link for the judges:
[https://sheets-analyzer.vercel.app/]

In this short pitch video, I demonstrate:

A raw dataset from Google Sheets
How the system analyzes the data structure
How the same dataset is transformed into multiple visual summaries
How users can immediately explore and understand their data

The Story Behind It

Many people store important information in Excel or Google Sheets, but understanding that data often requires experience with charts, formulas, or analytics tools.

The real challenge is not collecting data—it’s making sense of it.

I built this project to reduce that gap by making data interpretation more accessible. By automating visualization, summaries, and presentation—while supporting multiple languages—the tool helps users focus on understanding their data rather than struggling with technical barriers.

Technical Highlights

Data ingestion from Excel files and Google Sheets
Automatic schema detection (numeric, categorical, time-based columns)
Logic for mapping data structures to charts, tables, and summaries
Live, reactive visual output in a web-based UI
Multi-language interface support
Clear separation between data interpretation and visual rendering, making the system easier to extend in the future

Use of Mux (Additional Prize Category Participants Only)

Mux is used as the video infrastructure for this project’s pitch and demo presentation.

I uploaded the final edited pitch video to Mux and embedded it directly into this DEV submission. Mux provided reliable video hosting and playback, allowing the focus to remain on clearly communicating the project within the one-minute format required by the challenge.

❗ By submitting this project, I confirm that my video adheres to Mux's terms of service:
https://www.mux.com/terms

DEV Community: Jefri Bulo'

PuskesmasAI: Finishing an Offline AI Triage App for Rural Indonesia

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

PuskesmasAI: Finishing an Offline AI Triage App for Rural Indonesia

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

Google I/O 2026: We're Not Building Apps Anymore — We're Deploying Agents

Google I/O 2026: We're Not Building Apps Anymore — We're Deploying Agents

The Phrase That Actually Matters

What Actually Shipped (That You Should Care About)

Antigravity 2.0 — The Part Everyone Will Miss at First

Firebase — Quietly Doing a Lot

Flutter 3.44 — Bigger Than It Sounds

Gemini 3.5 Flash + WebMCP + SynthID

My Honest Read on All of This

The Part Google Didn't Say

So What Does This Mean for Us?

Conversa — A Multi-Agent AI Platform Powered by Gemma 4

Conversa — A Multi-Agent AI Platform Powered by Gemma 4

What I Built

🎙️ Meeting Analyzer (Audio Agent)

📄 Brief Generator (Document Agent)

🖼️ Whiteboard Analyzer (Image Agent)

Demo

Code

How I Used Gemma 4

Model Choice: google/gemma-4-26b-a4b-it (26B MoE)

Pipeline Architecture

AI Demystified: What I Learned from IBM Dev Day

AI Demystified: What I Learned from IBM Dev Day

AI #IBMDevDay #DeveloperJourney

From Data to Insight: Turning Spreadsheets into Visual Understanding

Model Choice: `google/gemma-4-26b-a4b-it` (26B MoE)