DEV Community: Hemalatha Nambiradje

Google I/O 2026 Blew My Mind — Here's What It Means for the Family App I'm Building

Hemalatha Nambiradje — Thu, 21 May 2026 18:37:46 +0000

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

I went into Google I/O 2026 as someone still finding her footing in app development. I came out the other side genuinely excited — and a little overwhelmed — about how fast everything is moving.

I am an SDET with 9 years in software testing. A few months ago I started learning AI fundamentals and building my first real app: a family super-app that combines grocery tracking, shopping budgets, family calendar planning, and weekend activity planning all in one place. I am building it in Google AI Studio using Gemini 3 Flash Preview.

So when I watched Google I/O this week, I wasn't watching as a passive observer. I was watching as someone actively building — and almost every announcement had me pausing the stream thinking "wait, that changes what I'm building."

Here are the moments that hit hardest.

1. Antigravity Built a Full OS in 12 Hours for Under $1,000

This was the jaw-drop moment of the entire keynote for me.

Google unveiled Antigravity 2.0, their agent-first development platform with a new Antigravity CLI for orchestrating and building agents. But the live demo went further than any announcement slide could capture — an AI agent was given a single prompt and built a functioning operating system in approximately 12 hours at a cost of under $1,000.

Let that sink in. A full OS. Twelve hours. Less than a thousand dollars.

As someone coming from a quality engineering background with limited development experience, this felt like the ground shifting. The barrier to building software just got dramatically lower. I have been spending weeks learning how to wire up a Node.js backend. Antigravity is showing a future where you describe what you want and the agent scaffolds it, writes it, and tests it.

What this means for my app:

I am building a family app with multiple moving parts — grocery lists, budget tracking, a family calendar, a weekend planner. Normally that scope would take a solo developer months. With agentic coding tools like Antigravity, I can see a future where I describe a feature in plain English, the agent writes the code, and I use my QE skills to review and test what it produced.

That is a workflow I genuinely understand. I have been testing other people's code for 9 years. Now the "other developer" is an AI agent, and my job is the same: find the gaps, validate the output, ship with confidence.

2. Agentic Coding in Search — Robby Stein's Demo

The Search keynote by Robby Stein was the section I rewatched twice.

Google Search introduced an AI-powered experience that generates contextual answers, images, and short videos, making it more assistant-like in function. Generative UI was also unveiled, dynamically adjusting how results appear based on user intent.

What struck me was how Search is no longer just a lookup tool. It is starting to reason. It doesn't just find — it understands what you are trying to accomplish and adapts the results to help you get there.

As someone building a family app, this matters because families don't search like developers do. A parent doesn't type "quinoa recipe low sodium 4 servings." They type "something healthy for dinner the kids won't complain about." The new Search understands that intent. It adapts.

What this means for my app:

I want to build a search experience inside my family app that works the same way. Not a filter. Not a dropdown. A natural language input where a family member types "we have chicken and we're on a budget this week" and the app understands the whole context — the ingredients they have, their budget remaining, what's already on the grocery list — and surfaces a meal plan that fits.

That's the bar Google just set. And it's the bar I'm now designing toward.

3. Gemini Spark — The 24/7 Background Agent

Gemini Spark is a new AI agent that lives in the cloud and works proactively on tasks in the background, continuing to work even when you're not actively using it.

This one I am still processing. An agent that doesn't wait for you to ask. It monitors, plans, and acts — all while you go about your day.

For a family app, the implications are significant. Most family planning apps are reactive — you open the app, you add something, you check a list. Gemini Spark represents a shift to proactive. The agent notices that your grocery budget is running low mid-week, checks the family calendar and sees there's a dinner party on Saturday, and quietly starts building a shopping list without you having to ask.

What this means for my app:

The Weekend Planner feature I've been designing fits perfectly here. Right now I was planning it as a manual feature — family members add activities, the app shows a view. But after watching Spark, I'm rethinking it as a proactive agent:

Monday: Spark notices the weekend is approaching and checks the family calendar
Tuesday: Spark suggests 3 weekend activity options based on past preferences and local weather
Wednesday: Family approves a plan — Spark generates the shopping list and budget estimate
Friday: Spark sends a reminder with the full weekend plan and what's still needed

That's not a feature. That's a family assistant. And Google just showed us it's possible.

4. Universal Cart — The Feature I Am Most Excited to Integrate

Universal Cart uses AI to proactively check your cart and understands context — like knowing which parts you're buying for a PC build — across multiple retailers.

This was the announcement I immediately started sketching integration ideas for.

Families don't shop at one store. We go to Costco for bulk, Metro for fresh produce, Shoppers for pharmacy items. Every week we're mentally tracking prices across multiple places. Universal Cart is Google saying: you shouldn't have to do that.

What this means for my app — in detail:

Here is exactly how I see Universal Cart fitting into the family app I am building:

Smart grocery sourcing:
A family member adds "Greek yogurt" to the shared grocery list. Universal Cart checks across nearby stores, finds the best price per unit, and flags it. The app shows: "Metro has this $1.20 cheaper this week."

Budget-aware shopping:
The family sets a $200 weekly grocery budget. As items get added to the list, the app estimates the Universal Cart total in real time. When you hit $180, the app flags it: "You're close to your budget — here are 3 items with cheaper alternatives."

Weekend planner tie-in:
Planning a family BBQ this weekend? The weekend planner generates a suggested menu. Universal Cart sources every ingredient across nearby stores, finds the best combination of stores to hit, and estimates the total cost before anyone leaves the house.

Receipt reconciliation with ReceiptMind:
After shopping, you photograph the receipt in ReceiptMind. The app compares what Universal Cart estimated vs what you actually spent. Over time, this builds a real picture of where estimates were off and which stores are consistently cheaper for your family's actual buying habits.

This integration is my north star for the next phase of this app.

5. Intelligent Eyewear — I Already Live in This World (Sort Of)

Google's collaboration with Samsung brought working demos of intelligent eyewear designed by Warby Parker and Gentle Monster, with deep Gemini integration to perform tasks through voice commands.

Here's my personal take on this one: I own a pair of Meta Ray-Bans.

I love them. I use them for calls. I take photos with them. But that is essentially it. The AI assistant on them feels like a novelty — it can answer general questions but it doesn't know anything about me, my context, or what I'm actually trying to do.

What Google showed at I/O is a fundamentally different vision. Gemini embedded in glasses that actually understand your context — what you're looking at, where you are, what you're trying to accomplish — and assists without you having to pull out your phone.

What this means for families:

I walked into a grocery store last Saturday with a list on my phone. I kept having to unlock it, find the list, check off items, put it back. It's friction. Small friction, but friction.

Intelligent eyewear with Gemini could eliminate that entirely. Walk into Metro, say "what do we still need?" — the glasses check the family list, see what's already in the cart via camera, and tell you what's missing. No phone. No unlocking. No friction.

For my family app, this is a future integration worth designing toward today — even if the hardware isn't available yet. Building the API layer to support a glasses interface means we're ready when the hardware ships this fall.

The Bigger Picture — What Google I/O Meant to Me Personally

I came into this as an SDET who made a decision a few months ago to stop watching AI from the sidelines and start building.

Google I/O showed me how fast the gap between "idea" and "working software" is closing. Antigravity is compressing development time. Search is raising the bar for what users expect from interfaces. Spark is redefining what "proactive" means in software. Universal Cart is eliminating friction that users didn't even know they were tolerating.

As a quality engineer, my job has always been to ask: does this actually work for the person using it? That question doesn't change with AI. If anything, it gets more important — because when AI agents are doing the building and the reasoning and the planning, the human who validates the output becomes more valuable, not less.

That's the role I'm stepping into. And Google I/O 2026 gave me a much clearer picture of what I'm stepping into it for.

What I'm Building Next

Immediately after I/O, I added three things to my roadmap for the family app:

Weekend Planner v2 — redesign as a proactive agent, not a manual feature
Universal Cart integration — research the API, start designing the budget overlay
Voice-first grocery list — design the UX today so it's glasses-ready when the hardware ships

The deadline for this writing challenge is May 24. My app has no deadline. But Google I/O just gave it a much clearer direction.

Hemalatha — SDET and app builder patiently waiting for the Gemini upgrade

Building a family super-app with Google AI Studio + Gemini 3 Flash Preview

I Built an AI Receipt Scanner with Gemma 4 — As an SDET with No Dev Background

Hemalatha Nambiradje — Tue, 19 May 2026 13:42:05 +0000

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

My Honest Starting Point

I want to be upfront about something before diving in: I am an SDET — a Software Development Engineer in Test. My world is test automation, quality assurance, and finding bugs, not building apps from scratch. I have spent the last few weeks learning AI fundamentals, experimenting with different models, trying to understand how this whole ecosystem actually works beneath the surface.
When I came across this hackathon, my first instinct was to scroll past it. This is for developers. But then I thought — why not? The worst that happens is I learn something.
What followed was equal parts confusion, accidental discovery, and a working app I am genuinely proud of.

The Gemini vs Gemma Confusion (I Suspect I'm Not Alone)

My first stop was Google AI Studio. And honestly? It was fantastic for getting ideas off the ground quickly. I built a small app there, got a feel for prompt engineering, and started to understand how multimodal models work.
But there was a problem: every time I tried to use Gemma 4, Google AI Studio kept routing me to Gemini Flash Preview — the latest hosted model. No matter what I selected, it defaulted back to Gemini.
I spent an embarrassing amount of time thinking I was using Gemma 4 when I wasn't.
That confusion forced me to actually sit down and research the difference. And that is when it clicked:

Gemma is not a smaller Gemini. They share research lineage, but the deployment story is completely different. Once I understood that, everything else fell into place.

What I Built: ReceiptMind

ReceiptMind is an AI-powered receipt scanner that extracts structured data from receipt photos and builds an expense dashboard automatically.
You take a photo of a receipt — any receipt, any store — upload it, and Gemma 4 reads the image and returns:

Merchant name
Total amount
Date
Expense category (Food & Dining, Groceries, Transport, Healthcare, Entertainment)
Tax amount

No manual entry. No OCR pipeline. No template matching. Just Gemma 4 looking at the image and understanding it.
This started as a feature I wanted to add to a personal finance app I have been quietly building on the side. The hackathon gave me the deadline I needed to actually ship something.

Why Gemma 4 26B MoE — Not the Other Models

This is the question I care most about answering, because I made this choice deliberately.
The Gemma 4 family has four models:

I chose the 26B MoE (A4B) for two specific reasons:

It is the only model in the family with native image input.
ReceiptMind's entire value is reading receipt photos. Without multimodal vision, there is no product. The E2B and E4B are text-only. The 31B dense is text-only. Only the 26B MoE can receive an image and reason about what it sees.
Despite 26B total parameters, only 4B activate per token.
This is the Mixture-of-Experts efficiency. The model routes each token through only the most relevant expert layers — so I get near-31B quality visual reasoning at a fraction of the compute cost. For a hobby project running on a free API tier, this matters enormously.

I also used the 256K context window to pass multiple receipts in a single prompt when generating monthly spending insights — no chunking, no retrieval, just the full history in one shot.

The Tech Stack

Frontend → HTML + Vanilla JavaScript
Backend → Node.js + Express
AI → Gemma 4 26B MoE via OpenRouter (free tier)
Database → Neon Postgres (serverless)
File Upload → Multer (in-memory buffer → base64)

Why OpenRouter?
Google AI Studio kept routing me to Gemini Flash. OpenRouter gave me direct access to google/gemma-4-26b-a4b-it:free with no credit card and no routing surprises. Once I found it, the API worked on the first try.

How It Works — The Architecture

User uploads receipt image
↓
Express backend receives file via multer
↓
Image converted to base64
↓
Sent to OpenRouter → Gemma 4 26B MoE (multimodal)
↓
Gemma reads the image, returns structured JSON
↓
JSON saved to Neon Postgres
↓
Dashboard updates with new receipt + running totals

The Core API Call

Here is the exact call that makes ReceiptMind work. The key is the image_url content block — this is what tells Gemma 4 to look at the receipt image:

const response = await fetch("https://openrouter.ai/api/v1/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.OPENROUTER_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "google/gemma-4-26b-a4b-it:free",
    messages: [
      {
        role: "user",
        content: [
          {
            type: "image_url",
            image_url: { url: `data:${mimeType};base64,${base64Image}` }
          },
          {
            type: "text",
            text: `Look at this receipt and extract the data. 
            Reply ONLY with JSON:
            {
              "merchant": "store name",
              "amount": 12.50,
              "date": "2026-05-14",
              "category": "Food & Dining",
              "tax": 1.10
            }`
          }
        ]
      }
    ]
  })
});

No OCR library. No preprocessing. No regex parsing of receipt text. Gemma reads the image exactly like a human would and returns clean structured data.

Test Receipts — What Gemma 4 Had to Handle

I tested with 5 real-world receipt types, each designed to stress-test different extraction challenges:

The gas receipt was the toughest — 42.45L @ $1.649/L = $69.96. Gemma extracted both the unit price and total correctly without any hints.

The entertainment receipt had a discount applied before tax, which changes the subtotal calculation. Gemma handled it correctly.

What Broke (And How I Fixed It)

**Problem 1: **The request would hang indefinitely
The free-tier model on OpenRouter can be slow during peak hours. I added a 30-second AbortController timeout so the frontend shows a proper error instead of spinning forever.

const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 30000);

Problem 2: Gemma sometimes wraps JSON in markdown code fences
The model would return

json { ... }

instead of raw JSON. Fixed with a one-liner:

const clean = rawText.replace(/json|/g, "").trim();

Problem 3: I had no idea what was failing
As an SDET, my instinct was to add logging everywhere. I added console.log checkpoints at every step (file received → base64 converted → API called → response received → JSON parsed → DB saved). This immediately showed me exactly where things were failing during development.

The Expense Dashboard

After scanning receipts, the dashboard shows:

Running total across all receipts
Breakdown by category (Food & Dining, Groceries, Transport, etc.)
Full receipt log with merchant, amount, date, and category
Per-receipt tax tracking (useful for expense reports)

After scanning all 5 test receipts, the dashboard showed a combined $369.70 across 5 categories — exactly matching the manual totals.

What This Means for My Pet Project

ReceiptMind started as one feature of a larger personal finance app I have been building. The plan is to integrate it so users can:

Scan receipts throughout the month
Get AI-generated spending summaries ("You spent 40% more on dining this month")
Set budget alerts by category
Export expense reports for tax season

The 256K context window is what makes the spending insight feature viable — I can pass the entire month's worth of receipts in one prompt and ask Gemma to reason across all of them at once.

What I Learned as an SDET Doing This

A few things surprised me:

1. Prompt engineering is just test case design.
Writing a good prompt felt exactly like writing a good test spec — be precise, cover the edge cases, define the expected output format. The skills transferred more than I expected.

2. The model choice matters more than I thought.
I initially assumed any capable model would work. But switching from text-only to multimodal was the difference between having a product and not having one.

3. The confusion between Gemini and Gemma is real.
If you are just getting started, burn this into your memory: Gemma = open weights you run yourself. Gemini = Google's hosted API. They are different products built from related research.

4. Ship something small and real.
I could have tried to build the full personal finance app. Instead I picked one feature, made it work end-to-end, and learned more in a week than I had in the previous month of reading documentation.

GitHub Repository
🔗 https://github.com/Hema-Nambi/ReceiptMind

Try It Yourself

Requirements:

Node.js 18+
Free OpenRouter account → openrouter.ai
Free Neon database → neon.tech

git clone https://github.com/Hema-Nambi/receiptmind
cd receiptmind
npm install
# Add your keys to .env
node server.js
# Open http://localhost:3000

Built during the Gemma 4 Challenge — May 2026

When Prompts Go Wrong: Hidden Risks in AI Every QA Engineer Must Know

Hemalatha Nambiradje — Thu, 14 May 2026 03:07:40 +0000

🚨 AI systems are only as secure as their prompts.

As QA engineers, we test inputs every day — but are we testing our AI prompts the same way?

I explored 5 real prompt risks that can silently break AI systems:

🔴 Prompt Injection — users override system rules with malicious instructions
🔴 Prompt Hijacking — tasks get redirected to extract hidden instructions
🔴 Prompt Poisoning — bad data corrupts model outputs
🔴 Prompt Leaking — hidden system prompts get exposed
🔴 Jailbreaking — safety guardrails get bypassed entirely

These aren't theoretical. They are testable, production-level risks.

And QA engineers are exactly the right people to catch them. 🎯

📖 Read the full breakdown with real examples here:
👉 https://hemaai.hashnode.dev/when-prompts-go-wrong-hidden-risks-in-ai-every-qa-engineer-must-know

Prompt engineering is not just about better answers — it's about building safe and reliable AI. 🛡️

QualityEngineering #AITesting #PromptEngineering #PromptInjection #SDET #QA #AISecurity #LearningInPublic

How QA Evaluates Generative AI Models

Hemalatha Nambiradje — Thu, 30 Apr 2026 13:18:54 +0000

Evaluating Generative AI is not just about a single accuracy score. Metrics like ROUGE, BLEU, and BERTScore each measure different aspects of quality — coverage, precision, and meaning.

From a QA perspective, real confidence comes from combining:

automated metrics
human evaluation
business expectations

I wrote a deeper breakdown here
Read more: https://hemaai.hashnode.dev/why-one-metric-is-never-enough-to-evaluate-generative-ai

Learning and sharing one concept at a time

Fine‑Tuning Isn’t Optional for Production‑Ready AI

Hemalatha Nambiradje — Wed, 29 Apr 2026 13:15:55 +0000

Foundation models are powerful, but out‑of‑the‑box they’re rarely production‑ready. Fine‑tuning is what helps align AI systems with real business needs, safety expectations, and quality standards.
From a QA engineer’s perspective, fine‑tuning—through approaches like instruction tuning and RLHF—is critical for improving reliability, consistency, and trust in AI outputs.
I’ve shared a deeper breakdown of:

what fine‑tuning really means
why it’s needed for production systems
how QA principles apply to data preparation and evaluation

Read the full post here:
https://hemaai.hashnode.dev/fine-tuning-isn-t-optional-how-qa-engineers-make-ai-models-production-ready
Learning and sharing one day at a time

Understanding the Generative AI Application Lifecycle

Hemalatha Nambiradje — Thu, 23 Apr 2026 12:59:23 +0000

Generative AI isn’t just about writing prompts — real applications follow a clear lifecycle: defining a use case, selecting the right foundation model, improving performance, evaluating results, and deploying responsibly.
Understanding this lifecycle is key to building AI systems that are reliable, testable, and useful in the real world.
I’ve shared a concise breakdown of the Generative AI application lifecycle here
👉 Read more: https://hemaai.hashnode.dev/building-generative-ai-applications-the-right-way
Learning and sharing one concept at a time 🚀

GenerativeAI #ArtificialIntelligence #SoftwareEngineering #LearningInPublic #QualityEngineering

Why ML Models Break After Deployment

Hemalatha Nambiradje — Tue, 21 Apr 2026 13:08:28 +0000

Many machine learning models perform great during training—but start failing once they reach production.
From my recent learning in MLOps and AI testing, I’ve realized that the issue isn’t usually the model itself. It’s the lack of operational practices like monitoring, drift detection, safe deployments, and retraining.
I wrote a short post explaining:

why ML models degrade in production
how data and concept drift impact predictions
where MLOps and QA make a real difference

Read the full article here:
https://hemaai.hashnode.dev/why-machine-learning-models-break-after-deployment
Would love to hear how your teams handle ML failures in production

QA Engineers Have an Unfair Advantage in Machine Learning

Hemalatha Nambiradje — Sat, 18 Apr 2026 01:07:34 +0000

Most ML models don’t fail because of bad algorithms.
They fail because no one properly evaluates them.

That’s where a QA mindset changes everything.

⸻

Think Like a Tester, Not Just a Builder

In ML:

Training = writing code
Validation = testing & tuning
Test set = final regression

👉 Sound familiar?

⸻

⚖️ The Real Risk Isn’t Accuracy

Overfitting → model memorizes data
Underfitting → model misses patterns
Goal → a balanced model that generalizes

💡 “High accuracy” can still mean a bad model.

⸻

📊 Metrics That Actually Matter

Stop relying only on accuracy:

Precision → Are predicted defects actually defects?
Recall → Are we missing critical defects?
MSE / R² → For predicting numbers

👉 In QA terms: Missing a bug is worse than a false alarm.

⸻

💼 If It Doesn’t Help the Business, It’s Useless

A model isn’t successful because it scores well.
It’s successful if it creates impact.

A/B testing
Canary deployments

👉 Same principles as production rollouts in QA.

⸻

💭 Final Thought

We’re not just testing features anymore.
We’re testing intelligence.

And honestly? QA engineers are built for this.

⸻

🔗 Read the full breakdown:
https://hemaai.hashnode.dev/evaluating-ml-models-like-a-qa-engineer-not-a-data-scientist

Breaking Things and Building Better Tests: A Hackathon Snapshot

Hemalatha Nambiradje — Thu, 16 Apr 2026 20:18:12 +0000

I recently participated in the Breaking Things Hackathon hosted by Hashnode and sponsored by Bug0, and it turned out to be a genuinely fun and refreshing experience.
What made this hackathon special for me was how closely it aligned with my day‑to‑day work. As a Senior SDET, I use Playwright extensively with a traditional Page Object Model (POM) approach—defining locators, managing workflows, handling inheritance, and constantly maintaining selectors as the UI evolves. While powerful, this style often means spending more time on framework maintenance than on actual testing.
During the hackathon, I explored Playwright with Passmark, and the difference was immediately noticeable.
I didn’t have to worry about finding each element, writing XPath selectors, or structuring complex POM classes. Instead, I could focus on user flows and test intent. The tests were easy to read—even for someone without a strong coding background—and extremely quick to create. In a short time, I wrote close to 30 regression tests that were fast, stable, and surprisingly resilient thanks to self‑healing capabilities.
Another highlight was how effortless cross‑browser testing felt. With minimal setup, I could execute tests across browsers without additional configuration or boilerplate.
This hackathon challenged a few long‑held assumptions for me:

Automation doesn’t need to be complex to be effective
Tests don’t have to be hard to read to be reliable
AI can genuinely boost tester productivity, not complicate it

You can find the project I worked on here:
https://github.com/Hema-Nambi/passmark-project

A big thank you to Hashnode for hosting and Bug0 for sponsoring such a great event. Hackathons like this encourage learning by doing and make space for testers to explore modern, AI‑driven approaches to quality engineering.

Read the full post on Hashnode: https://hemaai.hashnode.dev/breaking-things-and-building-better-tests-my-hackathon-experience?

Making AI Work With Humans — Not Against Them

Hemalatha Nambiradje — Wed, 15 Apr 2026 19:00:56 +0000

AI is getting smarter every day — but today I learned something more important than model size or accuracy.

AI is only valuable if it works with humans, not instead of them.
Today’s learning focused on human‑centered AI, feedback‑driven learning, and safety — the pillars that turn AI from a risky black box into a trusted partner.
Key Takeaways

Human‑Centered Design (HCD)
AI should support human decision‑making, not override it.
Good AI explains uncertainty, highlights risks, and keeps humans in control.

Reinforcement Learning from Human Feedback (RLHF)
AI improves by learning from human preferences — not just data.
This is what makes modern AI more helpful, aligned, and safer.

Safety & Transparency
Powerful AI without explainability is a liability.
Trust comes from knowing why a model behaves the way it does — and when humans should step in.

Why This Matters for QA & Engineering
Testing AI isn’t just about accuracy and performance.
It’s about trust, explainability, bias detection, and safe failure paths.
QA teams are becoming the ethical guardians of AI systems.
The future of AI isn’t autonomous — it’s collaborative.

Read the full post on Hashnode:
https://hemaai.hashnode.dev/making-ai-work-with-humans-not-against-them

The Machine Learning Development Lifecycle (And Why QA Matters)

Hemalatha Nambiradje — Wed, 15 Apr 2026 16:45:57 +0000

Machine learning doesn’t fail because models are bad.
It fails because quality is ignored across the lifecycle.
As a Quality Engineer, this realization was eye‑opening.
ML isn’t just training a model — it’s a continuous lifecycle:

business goals
problem framing
data processing
model development
deployment
monitoring
retraining

And QA has a role in every single stage — from defining testable goals to detecting data drift and regression issues in retrained models.
If ML systems are probabilistic, data-driven, and constantly evolving…
then testing must focus on behavior, not just logic.
👉 Read the full deep dive on Hashnode:
https://hemaai.hashnode.dev/the-machine-learning-development-lifecycle-and-why-qa-is-critical-at-every-stage

First Post on DEV — A Quick Hello

Hemalatha Nambiradje — Wed, 15 Apr 2026 15:14:42 +0000

This is my first article on DEV.to, and I’m excited to share my learning journey here.
I’m a Senior SDET with 9 years of experience in software testing and quality engineering, and I’ve recently started learning how machine learning and AI systems are built, deployed, and tested. Through this series, I’m documenting what I learn—from a QA and testing perspective—and sharing practical insights that engineers can apply in real systems.
If you’re a:

QA / SDET
Software engineer
Data or ML practitioner
Or someone curious about testing AI systems

…I hope you’ll find this useful.
I’d love your feedback, questions, or different perspectives in the comments
Let’s learn together.