DEV Community: Sireesha Pulipati

Agents are building their own UIs now. Here's when that's worth doing.

Sireesha Pulipati — Wed, 29 Apr 2026 21:02:06 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

During the developer keynote at Google Cloud NEXT '26, Google built an entire multi-agent system live on stage: a marathon planner that simulates routing a race through Las Vegas. The demo wasn’t just about the agents coordinating route planning, logistics, and runner simulation. It was about the interfaces those agents generated on the fly.

The route planning view showed a map with the proposed path, landmarks, and distance markers. The evaluation view displayed score breakdowns with both deterministic criteria (exactly 26.2 miles) and nondeterministic ones (community impact). The simulation view tracked live runner positions, traffic patterns, hydration stations, and Port-A-Potties. Each phase needed a different interface, and the agent built what it needed in real time using A2UI and the GenUI SDK for Flutter.

The keynote also highlighted FinnishIt, an AI-powered Finnish language tutor built with GenUI. Give it a topic and it generates custom flashcard decks specific to that context. Role-play scenarios shift from text exercises to tap-and-drag word puzzles to fill-in-the-blank modules depending on what the AI assesses you need right now.

Every session produces a different interface.

That's the point where I stopped treating A2UI as conference noise and started paying attention.

A2UI is an open standard Google donated to the community at NEXT '26. It lets agents generate UI dynamically at runtime. The GenUI SDK for Flutter is the developer-facing layer that makes it practical to build with. Most coverage either skipped it or described it without asking the more useful question: when does this actually make sense to use?

Where GenUI earns it

The marathon planner works because the interface IS the orchestration experience. Different workflow phases need different visualizations: route planning requires a map, evaluation needs scoring charts, simulation shows a live timeline.

FinnishIt works the same way for adaptive learning. There's no predetermined layout that serves a user practicing spoken conversational Finnish the same as one drilling grammar for the YKI citizenship test.

The right exercise type, difficulty, and interaction pattern depend on what the AI assesses the user needs right now. Hardcoding any of that produces a worse product.

The dynamic generation isn't a feature on top of the app. It is the app.

The same logic applies to onboarding flows, and this is where I think GenUI has untapped potential.

Most onboarding flows are static decision trees in disguise. You collect preferences on screen one, goals on screen two, then route users down one of two or three predetermined paths. The result feels personalized but is just filtered content behind a fixed interface.

Consider a personal finance app. Someone who opens it saying "I want to stop overspending" has a completely different mental model than someone who says "I want to start investing" or "I have irregular income and need to plan around it." Those aren't just different content buckets. They're different journeys, with different concepts to introduce, different decisions to make up front, and a different definition of what "getting to value" even means.

A GenUI-powered onboarding flow could read what a user brings to that first session and generate the next step as a direct response: not a static screen two, but a computed one.

A personal style app makes the case even more clearly, because here the interaction type itself changes, not just the content.

Someone who opens a style app saying "I have a job interview next week" needs an occasion-specific outfit construction flow: clear goal, tight timeline, specific constraints. Someone who says "I'm trying to figure out my personal style" needs a discovery experience: visual-first, exploratory, maybe swipe-on-images or mood board style. Someone who says "I want to build a capsule wardrobe on a budget" might need a wardrobe audit flow that starts with photographing what they already own.

These are not variations on the same form. They require different interface primitives: camera, swipe cards, visual grids, checklists. GenUI earns it here because you genuinely cannot know which one to show until the user tells you what they're trying to do.

The right interaction depends on the context. The context arrives at runtime.

A decision filter

Before reaching for GenUI, three questions:

Is the interface the experience, or is it a container for a fixed one?
In FinnishIt, the dynamically generated exercise is the product. That's different from a news reader or a task manager, where content arrives through a stable interface. Not every app benefits from a layout that changes each session.

Does the user need to find the same thing in the same place next time?
Adaptive learning, personalized onboarding, style discovery: each session is meant to feel different. An e-commerce checkout, a settings screen, a navigation menu: users build trust and speed through repetition. Those interfaces earn nothing from variation.

Is this an exploratory action, or one that requires confident understanding of what's about to happen?
Payment confirmation, account deletion, anything irreversible: users need to know exactly what they're looking at. Dynamic layout introduces uncertainty at exactly the wrong moment.

Where it doesn't fit

The failure cases aren't about regulation or compliance. They're about what users need from an interface to trust it.

A checkout flow that looks different each time isn't personalization. It's friction.

High-frequency task interfaces derive part of their value from the fact that users can operate them without thinking. Email, task management, booking flows: variability works against that entirely.
There's also a quieter design system concern. Most product teams ship against a component library: specific tokens, spacing rules, interaction patterns. An agent that approximately matches those patterns is not the same as one that respects the contract. That gap shows up in production in ways that are hard to articulate and easy to notice.

The open bet

A2UI and GenUI aren't solutions looking for a problem. There's a real category of app where static UI has always been the wrong answer: the kind where the right interaction depends on context that only arrives at runtime.

FinnishIt is an early, polished example of what that looks like when it's done well. Personalized onboarding, adaptive learning, style discovery: same category.

What I'm watching is whether developers build intuition for where this pattern belongs, or whether the next few years surface a wave of apps that introduced variability in exactly the places their users needed stability.

If you've seen agent-generated UI get it right, or quietly get in the way, I'd like to hear about it.

Why the Google Cloud Professional Data Engineer Certification Still Matters in an AI-First World

Sireesha Pulipati — Wed, 28 Jan 2026 05:57:23 +0000

Have you found yourself wondering recently whether cloud certifications still matter, especially now that AI can write SQL, generate pipelines, and suggest architectures?

Short answer: yes, arguably more than ever.

But the value just is not the credential. It is the depth of understanding the preparation forces you to develop.

The Google Cloud Professional Data Engineer certification was never about memorizing services or APIs. At its core, it has always been a structured way to internalize how data systems should be designed, operated, and evolved in real production environments.

In an AI-enabled world, that foundation matters more, not less.

Certification prep is about judgment

AI tools are powerful accelerators. They can draft code, propose architectures, and help debug issues. What they cannot reliably do is exercise engineering judgment in complex, real-world constraints.

Preparing seriously for the PDE exam pushes you to reason through questions such as:

When does streaming actually make sense versus batch?
How should reliability, cost, security, and governance be balanced?
What tends to fail first at scale, and how should systems be designed for that?
When is a simpler design the correct decision?

These are not trivia questions. They reflect the decisions practicing data engineers make every day. The exam tests whether you can reason through trade-offs, not whether you recognize product names.

How the exam has evolved

The Professional Data Engineer exam has evolved alongside the platform and the role itself.

Six or seven years ago, the exam covered a much broader surface area. It included significant emphasis on databases, analytics, and machine learning concepts. That breadth made sense at the time. Cloud data roles were still forming, and boundaries between responsibilities were less clear.

What has changed since then is not the philosophy of the exam, but its focus.

As Google Cloud introduced more specialized certifications, such as Associate Data Analyst, Professional Machine Learning Engineer, and Professional Database Engineer, those adjacent concerns moved into their own lanes. The PDE exam responded by narrowing its scope and going deeper.

Today, it is firmly focused on core data engineering responsibilities:

Designing secure and reliable data systems
Building and operating batch and streaming pipelines
Modeling, storing, and querying data at scale
Managing cost, automation, and operational reliability

That emphasis has always been present. What is different now is the level of concentration. With peripheral topics handled elsewhere, the exam prioritizes depth over breadth.

The quiet but meaningful 2025 exam guide update

The most recent exam guide update made this focus even clearer.

Data engineering for AI is now explicit

For the first time, the guide explicitly calls out responsibilities such as:

AI data enrichment within pipelines
Preparing unstructured data for embeddings
Supporting retrieval-augmented generation (RAG) workflows

These additions reflect how data engineering shows up in practice today.

Most data engineers are not building models end to end. They are enabling AI systems by ensuring data is reliable, enriched, governed, and retrievable at inference time. This includes handling unstructured data, managing feature pipelines, and supporting retrieval patterns that AI applications depend on.

Importantly, this does not turn the Professional Data Engineer exam into a machine learning exam. Model training and tuning remain the responsibility of ML engineers. What the PDE exam reinforces is a more fundamental truth:

AI systems succeed or fail based on data engineering quality.

The underlying competencies remain the same. Data modeling, pipeline design, reliability, cost control, and governance are still central. The difference is that the exam now names these AI-adjacent use cases explicitly, instead of assuming them implicitly.

“Data mesh” quietly disappeared

Another notable change is the removal of the explicit term “data mesh” from the guide.

This does not mean decentralization or domain ownership disappeared. It signals a shift away from buzzwords toward practical platform design, governance, and enablement. The exam now frames this work as building data platforms, not adhering to a specific architectural label.

That is a healthy evolution.

How to prepare today

If you are preparing for the PDE exam now, one principle matters more than any resource.

Do not study by service. Study by responsibility.

Map your preparation directly to the exam domains:

Designing data systems
Ingesting and processing data
Storing data
Preparing data for analytics and AI
Maintaining and automating workloads

For each domain, focus on trade-offs. Be able to explain why one approach is better than another in a given scenario. Anchor your understanding in production constraints such as cost, reliability, scale, and security. That is what the exam evaluates.

Final thought

The Professional Data Engineer certification is most valuable when treated as a learning framework, not a finish line. In a world where AI can generate solutions instantly, the differentiator is not speed. It is the ability to choose the right solution under real constraints. That is exactly what this certification, when approached thoughtfully, helps develop.