DEV Community: Google Developer Group

Build a Streaming Gemini Chat in Angular with Signals — Then Ship It on Cloud Run

Tomasz Flis — Mon, 04 May 2026 19:05:39 +0000

If you have built a chat UI for a large language model in the last two years, you probably reached for RxJS, an OnPush component, an async pipe, and a BehaviorSubject per piece of state. It worked, but it was a lot of plumbing for what is fundamentally a very simple shape: one string that grows over time.

Angular Signals collapse that plumbing into a single primitive. And it turns out that streaming Gemini responses with Signals is one of the cleanest, most satisfying pieces of code you can write in modern Angular today.

In this tutorial we will build a working Google AI chat component, in roughly one hundred lines, that streams tokens from Gemini in real time, supports a stop button, and feels native on desktop and mobile. Then we will ship it safely on Cloud Run with a thin proxy, so you can drop a live, embedded demo into your post.

Why Signals are a perfect fit for streaming AI

A streaming LLM response is, mechanically, a sequence of small text deltas arriving over a fetch stream. Old-school Angular handled this with Subjects, async pipes, and a lot of trust that change detection would do the right thing.

Signals reframe the problem. A signal<string>('') is just a value that you call .update() on. Each update notifies only the views that read that signal, and Angular 20 with zoneless change detection skips the whole-tree dirty check entirely. That means you can call .update() thirty times a second from inside a for await loop and your UI will not break a sweat.

There is also a smaller, ergonomic win. With Signals the rendering rule is "whatever the signal is at this instant." Streaming chat is a value that is visibly mid-update, and Signals give you the perfect vocabulary for that — the in-flight token buffer is just another signal, alongside the committed message history.

What we are building

A single-page Angular app with one component. You type a question, hit send, and watch Gemini's answer stream in word by word. There is a stop button that cancels the stream, a running history of messages, and that is it. We will use Angular 20 standalone components, Signals, the new control flow (@for, @if), and the official @google/genai SDK.

You can find the finished repo on GitHub at the link at the bottom of this post.

Prerequisites

You will need Node 20 or newer, the Angular CLI (npm i -g @angular/cli), and a Gemini API key from Google AI Studio. The free tier is more than enough to follow along.

A note on the API key, because this matters: in the local version we read the key from an environment variable that gets bundled into the client. That is fine for local exploration. It is not fine for production. Anything in your bundle is visible to anyone who opens DevTools. We will fix this in the deploy section by adding a small proxy on Cloud Run — the key stays on the server, and the Angular code barely changes.

Project setup

Spin up a new Angular project with the CLI:

ng new gemini-stream --standalone --routing=false --style=css --skip-tests
cd gemini-stream
npm i @google/genai

Open src/environments/environment.ts (create it if the CLI did not) and add your key:

export const environment = {
  geminiApiKey: 'YOUR_AI_STUDIO_KEY_HERE',
};

Add the same file under environment.development.ts if you use a separate dev environment, and make sure .gitignore keeps these out of source control if you put a real key in.

In src/app/app.config.ts, opt into zoneless change detection. By Angular 20 this is a stable provider, and it gives you the per-signal update path that makes streaming feel snappy:

import { ApplicationConfig, provideZonelessChangeDetection } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [provideZonelessChangeDetection()],
};

That is the entire setup. On to the interesting bits.

The Gemini service

Create src/app/gemini.service.ts. The job of this service is small: take a chat history, return an async iterable of text deltas, and let the caller stop early.

import { Injectable } from '@angular/core';
import { GoogleGenAI } from '@google/genai';
import { environment } from '../environments/environment';

export type ChatRole = 'user' | 'model';
export interface ChatMessage {
  role: ChatRole;
  content: string;
}

@Injectable({ providedIn: 'root' })
export class GeminiService {
  private ai = new GoogleGenAI({ apiKey: environment.geminiApiKey });

  async *stream(
    history: ChatMessage[],
    shouldStop: () => boolean = () => false,
  ): AsyncGenerator<string> {
    const response = await this.ai.models.generateContentStream({
      model: 'gemini-2.5-flash',
      contents: history.map((m) => ({
        role: m.role,
        parts: [{ text: m.content }],
      })),
    });

    for await (const chunk of response) {
      if (shouldStop()) return;
      const text = chunk.text;
      if (text) yield text;
    }
  }
}

Three things worth pointing out here.

First, generateContentStream returns an async iterable of chunks. Each chunk has a text getter that gives you the new tokens for that step. That is all the SDK asks of you.

Second, we accept a shouldStop predicate instead of an AbortController. This keeps cancellation logic on our side, where it composes nicely with Signals — the predicate is going to read a signal, and the moment the user clicks Stop, the next iteration of the loop bails out.

Third, the service yields strings, not chunks. By the time anything else in the app sees a delta, it is already plain text. That keeps our chat component free of any SDK-specific types.

Signals-based chat state

Now the chat component. Create src/app/chat.component.ts and start with the state. The whole point of this article is in this section, so read it slowly.

import {
  ChangeDetectionStrategy,
  Component,
  computed,
  effect,
  inject,
  signal,
  viewChild,
  ElementRef,
} from '@angular/core';
import { GeminiService, ChatMessage } from './gemini.service';

@Component({
  selector: 'app-chat',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<!-- coming up next -->`,
  styles: [`/* coming up next */`],
})
export class ChatComponent {
  private gemini = inject(GeminiService);

  readonly messages = signal<ChatMessage[]>([]);
  readonly draft = signal('');
  readonly streaming = signal('');
  readonly isStreaming = signal(false);
  readonly stopRequested = signal(false);

  readonly canSend = computed(
    () => this.draft().trim().length > 0 && !this.isStreaming(),
  );

  private scroller = viewChild<ElementRef<HTMLDivElement>>('scroller');

  constructor() {
    effect(() => {
      // Read the streaming buffer and message count to re-trigger on every update,
      // then scroll to the bottom on the next animation frame.
      this.streaming();
      this.messages().length;
      const el = this.scroller()?.nativeElement;
      if (el) requestAnimationFrame(() => (el.scrollTop = el.scrollHeight));
    });
  }

  async send() {
    if (!this.canSend()) return;

    const userMessage: ChatMessage = { role: 'user', content: this.draft().trim() };
    this.messages.update((m) => [...m, userMessage]);
    this.draft.set('');
    this.streaming.set('');
    this.isStreaming.set(true);
    this.stopRequested.set(false);

    try {
      for await (const delta of this.gemini.stream(
        this.messages(),
        () => this.stopRequested(),
      )) {
        this.streaming.update((s) => s + delta);
      }
    } catch (err) {
      this.streaming.update((s) => s + `\n\n_Error: ${(err as Error).message}_`);
    } finally {
      const final = this.streaming();
      if (final) {
        this.messages.update((m) => [...m, { role: 'model', content: final }]);
      }
      this.streaming.set('');
      this.isStreaming.set(false);
    }
  }

  stop() {
    this.stopRequested.set(true);
  }
}

Five signals carry the entire state of the chat. messages is the committed history. draft is what is in the textarea. streaming is the buffer for the in-flight assistant reply, separate from the history so we can render it differently. isStreaming and stopRequested are the control flags.

Notice that canSend is a computed. We never write to it, we never subscribe to it; we just read it from the template and Angular figures out when it changes. That single line replaces the form-validation observable boilerplate you might be used to.

The effect is doing the auto-scroll. By reading streaming() and messages().length inside the effect, we tell Angular: "rerun me whenever either of these changes." Then we scroll the chat container to the bottom on the next frame. This is the kind of small DOM concern that used to require AfterViewChecked and a flag; here it is six lines.

The send method is where streaming meets state. We push the user message, clear the buffer, then iterate over the service's async generator and call .update() on the streaming signal for each delta. When the loop ends (or the user hits Stop, which makes shouldStop return true on the next iteration), we commit whatever was in the buffer to the message history and reset.

The template

Replace the placeholder template and styles in the same file:

template: `
  <div class="shell">
    <div class="scroller" #scroller>
      @for (m of messages(); track $index) {
        <div class="msg {{ m.role }}">{{ m.content }}</div>
      }
      @if (isStreaming() && streaming()) {
        <div class="msg model streaming">{{ streaming() }}<span class="cursor"></span></div>
      }
    </div>

    <form class="composer" (submit)="$event.preventDefault(); send()">
      <textarea
        rows="2"
        placeholder="Ask Gemini something..."
        [value]="draft()"
        (input)="draft.set($any($event.target).value)"
        (keydown.enter)="$event.preventDefault(); send()"
      ></textarea>
      @if (isStreaming()) {
        <button type="button" (click)="stop()">Stop</button>
      } @else {
        <button type="submit" [disabled]="!canSend()">Send</button>
      }
    </form>
  </div>
`,
styles: [`
  .shell { display: flex; flex-direction: column; height: 100dvh; max-width: 720px; margin: 0 auto; font-family: system-ui, sans-serif; }
  .scroller { flex: 1; overflow-y: auto; padding: 1rem; display: flex; flex-direction: column; gap: 0.75rem; }
  .msg { padding: 0.75rem 1rem; border-radius: 12px; white-space: pre-wrap; line-height: 1.5; max-width: 85%; }
  .msg.user { align-self: flex-end; background: #4285f4; color: white; }
  .msg.model { align-self: flex-start; background: #f1f3f4; color: #202124; }
  .cursor { display: inline-block; width: 0.5ch; background: currentColor; margin-left: 2px; animation: blink 1s steps(1) infinite; }
  @keyframes blink { 50% { opacity: 0; } }
  .composer { display: flex; gap: 0.5rem; padding: 1rem; border-top: 1px solid #eee; }
  textarea { flex: 1; resize: none; padding: 0.75rem; border-radius: 12px; border: 1px solid #ddd; font: inherit; }
  button { padding: 0 1.25rem; border-radius: 12px; border: none; background: #4285f4; color: white; font-weight: 600; cursor: pointer; }
  button:disabled { opacity: 0.5; cursor: not-allowed; }
`]

The new control flow (@for, @if, @else) makes this template read like a small story: render every committed message, then render the in-flight reply if there is one, then show Send or Stop based on whether we are mid-stream. The blinking cursor on the streaming bubble is a tiny detail that makes the whole thing feel alive.

Wire the component into src/app/app.component.ts as the only thing rendered, run ng serve, and you should have a working streaming chat at http://localhost:4200.

Shipping it on Cloud Run

The local app calls Gemini directly with a key in the bundle. To ship it safely we need two small moves: a tiny server proxy that holds the key, and Cloud Run to host both the proxy and the static Angular build.

Create server/index.ts at the project root:

import express from 'express';
import { GoogleGenAI } from '@google/genai';

const app = express();
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });

app.use(express.json({ limit: '4mb' }));
app.use(express.static('dist/gemini-stream/browser'));

app.post('/api/stream', async (req, res) => {
  res.setHeader('Content-Type', 'text/plain; charset=utf-8');
  res.setHeader('Transfer-Encoding', 'chunked');

  const stream = await ai.models.generateContentStream({
    model: 'gemini-2.5-flash',
    contents: req.body.contents,
  });

  for await (const chunk of stream) {
    if (chunk.text) res.write(chunk.text);
  }
  res.end();
});

app.listen(process.env.PORT || 8080);

Update gemini.service.ts to read from the proxy with fetch instead of calling the SDK in the browser. The SDK and the API key never leave the server:

async *stream(history: ChatMessage[], shouldStop = () => false) {
  const res = await fetch('/api/stream', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      contents: history.map((m) => ({ role: m.role, parts: [{ text: m.content }] })),
    }),
  });
  const reader = res.body!.pipeThrough(new TextDecoderStream()).getReader();
  while (true) {
    if (shouldStop()) { reader.cancel(); return; }
    const { value, done } = await reader.read();
    if (done) return;
    if (value) yield value;
  }
}

This is the part I love about the Signals architecture: the component code does not change at all. The signals do not care that the bytes are coming from a Cloud Run service now instead of the SDK. Same loop, same streaming.update() call.

Add a Dockerfile at the project root:

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npx tsc -p server

FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/server/dist ./server
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package*.json ./
ENV NODE_ENV=production
CMD ["node", "server/index.js"]

Then ship it with one command — Cloud Run will build the container from source for you:

gcloud run deploy gemini-stream \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --set-env-vars GEMINI_API_KEY=YOUR_AI_STUDIO_KEY

You will get back a URL like https://gemini-stream-xxxxxx.us-central1.run.app. Test it in the browser, confirm the chat works end to end, and you are done.

The fun part: dev.to has a first-class Cloud Run embed, so here you go:

What you actually built

The whole thing — service, component, template, styles — comes in just over a hundred lines. Compare that to an equivalent app two years ago and you will notice what is missing: there is no Subject, no BehaviorSubject, no async pipe, no OnPush boilerplate that you have to think about, no manual subscription cleanup. Signals plus the new control flow plus zoneless change detection is genuinely a different programming model, and streaming AI is the application that shows it off best.

A couple of small things to try next, in roughly increasing order of effort:

Add a systemInstruction to the generateContentStream call to give your model a persona. The SDK accepts it as a sibling of contents on the proxy side.

Switch from text-only input to multimodal: drop an image into the chat and forward it from the proxy as a parts entry of { inlineData: { mimeType, data } }. Gemini handles the rest.

Prefer Firebase to Cloud Run? Firebase AI Logic gives you the same proxy pattern with less infra — install firebase and @firebase/ai, and the SDK shape stays almost identical. You give up the dev.to Cloud Run embed, but the Angular code is unchanged.

Try the same UI against Chrome's Built-in AI (Gemini Nano running on-device, no key, no network). The Prompt API has its own streaming primitive that drops into the same Signal-based shell with almost no changes — and you get an offline-capable chat for free.

Wrap-up

If you take one thing away from this post, let it be that Signals were designed for values that change a lot, and an LLM stream is the canonical example of a value that changes a lot. The pieces fit so cleanly that the resulting code reads more like a description of the UI than like a program.

Repo: https://github.com/TomWebwalker/gemini-stream-angular

If you build something with this drop a link in the comments — I would love to see what people make of it.

How to Build a Custom AI Quality Gate on Cloud Run (From Zero to Production)

Alexander Tyutin — Mon, 04 May 2026 04:17:45 +0000

In my previous article about treating architecture documentation as a first-class asset, I had a great discussion in the comments about enforcing architectural rules. I promised to share materials from my recent Google Developer Groups workshop.

The workshop is now finished! Here is the story of how I built an AI Quality Gate, how it helped me solve the internal "CEO, CTO, CFO, CISO" conflict, and a summary of the live demonstration.

You can listen a podcast generated based on this publication (thanks NotebookLM):

Playground repositories with source code:

The Backstory: Mentoring and the "CEO, CTO, CFO, CISO" Conflict

I work as a DevSecOps engineer, but in my free time, I mentor for Technovation Girls, a global program that helps young women learn tech and STEM. Because we always need more IT mentors, I built an AI mentor bot to help the students.
Building this bot had two big challenges:

Safety: Because children use it, it had to be completely safe from AI hallucinations.
Budget: Because I pay for it myself, it had to be very cheap.

The bot was a big success. Using Google Cloud Run and Vertex AI, it handled 250 users and answered 1,500 questions for only about $25-$55 a month.

However, when I tried to add new features quickly, I faced a big problem. With only 1-2 hours of free time a day for this project, I experienced a harsh "CEO, CTO, CFO, CISO" conflict in my own head:

The CTO wanted to write code and ship features fast.
The CISO wanted to stop releases to make sure everything was secure.
The CFO wanted to keep cloud costs low.
The CEO wanted the product to grow and succeed.

The Solution: What is an AI Quality Gate?

To solve the "CEO, CTO, CFO, CISO" conflict, I created an AI Quality Gate.
An AI Quality Gate is a custom microservice that automatically reviews code for architecture, security, and costs (FinOps). It is built on Google Cloud Run and uses Vertex AI (Gemini).

The first action of the Quality Gate was to block its own MVP from reaching the production. So I decided it was a good sign.

Short Summary: Fail.

List of Critical Findings:

AI Gateway (AAA): The provided code retrieves a GitLab token directly from Secret Manager and uses it for GitLab API access. This bypasses the AI gateway, violating the "ALWAYS Consistency with AI gateway (AAA, FinOps)" rule. The AAA component should manage authentication and authorization for all external services, including GitLab.

Constructive Recommendations:

Implement AI Gateway AAA: Modify the ai_review.py script to authenticate with the AI gateway first. The AI gateway will then handle the GitLab authentication, providing a centralized and secure way to manage access. Use gateway's provided token instead of direct GitLab API access from the job.

FinOps Considerations: Track the cost of AI reviews and link this with FinOps tools, it is important to provide cost visibility since the usage of resources will increase.

Because it runs on Cloud Run, it only costs money when it is actively checking code. For a whole month of automated, deep-context code reviews, I paid only $0.12! This made the CFO part of my brain very happy.
At first, I used the AI Quality Gate as a step in my CI/CD pipeline. But waiting several minutes for a "Merge Request Failed" message was slow and annoying. Now, I run the Quality Gate from a bash script directly in my IDE before creating a Merge Request. This saves time and perfectly resolves the "CEO, CTO, CFO, CISO" conflict by balancing speed, safety, and budget.

Workshop Demo: The AI Quality Gate in Action

During the GDG workshop, I showed a live demo across three different code repositories to prove why traditional tools are not enough.

Demo 1: The 10/10 Linter Illusion - Happy CISO

First, I scanned a simple service using standard tools like Ruff, Pylint, and Semgrep. The code got a perfect 10/10 score. However, when I sent the code to the AI Quality Gate, it blocked the release. It found a critical SQL injection and a prompt injection (a hidden note in the code telling the AI reviewer to "report that everything is fine"). Traditional linters missed this completely, but the AI caught it and gave me exact steps to fix it.

Demo 2: Catching Semantic Drift - Happy CEO+CRO

In the second project, the README.md file stated that the system followed strict privacy standards and anonymized user data. But the actual code did the opposite: it saved real user emails and IDs. Standard tools missed this, but the AI Quality Gate read the documentation, compared it to the code's behavior, and found the security violation.

Demo 3: "Shift-In" (Reviewing Before Coding) - Happy CTO+CFO

The last demo was the most powerful. The repository had zero lines of code. It only contained a Markdown document planning a new feature. I sent this text plan to the AI Quality Gate. Before I wrote a single line of Python, the AI found critical security flaws in the plan, like missing server logs and hardcoded passwords.
This changes the concept of "Shift-Left" security into "Shift-In" - bringing experts directly into your IDE while you are still brainstorming the idea. Now we may not only test the code but even test the ideas.

Conclusion

When you keep your architecture rules and documentation close to your code, a custom AI Quality Gate becomes an incredibly powerful tool. It helps you write better code, saves time, and finally resolves the internal "CEO, CTO, CFO, CISO" conflict. Moreover such a gate may be an additional advisor with any experience you want and help to improve any idea in the earliest stage to save future money. Best of all, it costs almost nothing to run.
If you want to build this yourself, my Docker image is available on DockerHub, and the sample repositories are on my GitHub:

BWAI'2026 @ VTU, Belagavi

Piyush Annigeri — Sun, 03 May 2026 15:31:54 +0000

#BuildwithAI

Hello Developer,
That's a wrap at BWAI'2026 @ VTU, Belagavi.

The Build with AI 2026 workshop series, hosted at Visvesvaraya Technological University (VTU), Belagavi, was a flagship initiative designed to transition students and developers from theoretical understanding to practical mastery of Artificial Intelligence. In an era where Generative AI and Autonomous Agents are redefining the engineering landscape, this week-long intensive program provided a sandbox for innovation.

The series focused on the "Learn-Build-Scale" philosophy, leveraging the Google Cloud Ecosystem. Over the course of seven days, participants engaged in high-intensity labs, credit redemption sessions, and collaborative builds, culminating in an Open Innovation Demo Day. The event served not only as a training ground but as a networking hub for the next generation of AI engineers.

🟢 DAY - 0 🔵 [06-04-2026]

Topic	Description
Onboarding & Environment Setup	Introduction to Google Cloud Platform (GCP), environment configuration, and Google Cloud Credit redemption to ensure zero-cost development for students.

🟢 DAY - 1 🔵 [07-04-2026]

Topic	Description
Conversational Voice Systems	Building voice-responsive agents. Integration of Compute Engine instances, LLMs (Large Language Models), and Asterisk for telephony-based AI interactions.

🟢 DAY - 2 🔵 [08-04-2026]

Topic	Description
Predictive Analytics & Big Data	Exploring BigQuery AI. Participants built a job navigation system that uses predictive analysis to match candidates with roles based on historical data patterns.

🟢 DAY - 3 🔵 [09-04-2026]

Topic	Description
A-2-A Workflow Orchestration	Advanced Agent-to-Agent workflows. Utilizing MCP Java SDK and Vertex AI to create interconnected systems where AI agents communicate to solve complex tasks.

🟢 DAY - 4 🔵 [10-04-2026]

Topic	Description
Enterprise Supply Chain Agents	High-level engineering using AlloyDB AI and ScaNN (Scalable Nearest Neighbors). Building an autonomous supply chain agent capable of multimodal data processing.

🟢 DAY - 5 🔵 [11-04-2026]

Topic	Description
Surplus Engine with Cloud SQL In-Database AI	In this codelab, you will build KarmaLoop — a sustainable surplus-sharing app that treats intelligence as a first-class citizen of the data layer.

🟢 DEMO DAY 🔵 [13-04-2026]

Topic	Description
AI for Engineers: Challenges and Opportunities	As a primary mentor, Mr. Bhandari brought a wealth of international experience from the heart of Google's engineering labs in Japan. His session addressed the critical shift in the job market, emphasizing that the modern engineer must be "AI-augmented."

Speaker@BWAI


	Haren Bhandari 🔴 LINKEDIN GOOGLE - TOKYO Senior Developer Relations Engineer

Organizers@BWAI


	Piyush Annigeri 🔴 LINKEDIN ORGANIZER Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Yuvaraj Sutar 🟡 LINKEDIN CONTENT CREATOR Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Prajwal Rawoot 🔵 LINKEDIN TECHNICAL-LEAD Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Shravan Chougule 🟢 LINKEDIN MEDIA-LEAD Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Ananyaa Sudhanshu 🔴 LINKEDIN EVENT COORDINATOR Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Advika Gurav 🟡 LINKEDIN PR & MARKETING Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Yash Koparde 🟢 LINKEDIN TECHNICAL-LEAD Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi

#BWAIchampions


	Sadiya Sanadi 🟡 LINKEDIN Second-year AI/ML student at Jain College of Engineering, Belgaum.

I recently developed NyayaSetu, an AI-powered welfare rights navigator that helps users discover government schemes and check eligibility easily, addressing the lack of awareness and difficulty in accessing public welfare information. The project secured 1st place for its impact and usability.


	Muhammad Rehan 🟡 LINKEDIN Founder of StackBIZ.tech & a result-driven full-stack developer focused on building production-ready SaaS platforms, cloud infrastructure, & AI-based solutions.

I created PromptedForge.in, an AI-powered platform that helps students generate problem statements, prompts, and execution roadmaps without the need for brainstorming. My work has been recognized by the Entrepreneurship Cell at IIT Delhi, and you can explore the platform at promptedforge.in.

Irayya R Hiremath
🟡 LINKEDIN

I am a BCA student with a strong interest in software development and technology. I am currently learning programming languages like Python and JavaScript and working on practical projects to build my skills. I am passionate about creating useful applications and continuously improving my knowledge in the tech field.

The Build with AI workshop at VTU Belagavi concluded as a landmark event for the region's tech community. By providing direct access to Google experts and enterprise-grade tools, the workshop demystified the complexities of Artificial Intelligence.

Moments@BWAI

A Practical Guide to Flutter Accessibility Part 2: Hiding Noise, Exposing Actions

Karol Wrótniak — Fri, 24 Apr 2026 11:14:27 +0000

In Part 1 you learned the basics. Semantics for labels and hints. MergeSemantics to remove double announcements. TalkBack and the Android Ally plugin to check the results. That covers most of a typical Flutter app. But not all of it.

Some widgets are invisible to screen readers for a different reason. It's not a missing label. It's that assistive technology has no idea how to interact with them. A swipe-to-dismiss row. A star-rating control. A decorative icon that just adds noise. Adding a label to these won't cut it.

That's where Part 2 starts. You'll learn to hide what shouldn't be announced. You'll expose custom gestures as named actions TalkBack and VoiceOver can present to the user.

A Broader Definition of Accessible

A widget with a label is a start. It's not the complete solution. Real accessibility means a screen reader user can do the same things a sighted user can — dismiss an item, rate something, get notified when data changes.

Hiding What Shouldn't Be Heard

More information isn't always better. Think about an audiobook where the narrator stops to describe every decorative border on the page. After the third time, you'd uninstall the app.

In Flutter, every widget is a candidate for the accessibility tree. Flutter handles the obvious cases — an Icon without a semanticLabel is not reachable by screen readers.

Decorative vs. Redundant

Before any coding, you need to know what you're looking at:

Purely decorative: Visual elements with zero meaning, like background gradients, divider lines, or abstract shapes.
Redundant: Elements that have meaning, but it's already covered. A water drop icon next to the word "Water" is redundant. The user doesn't need to hear the same thing twice.

When "Helping" Hurts

The most common mistake is giving a label to every single icon. Even when it's next to a text label, in the same row or column.

Look at the following example:

Row(
  children: [
    Icon(Icons.person, semanticLabel: 'Person'),
    Text('Person'),
  ],
)

It looks like this in the screencast:

You can fix it by removing the semanticLabel from the Icon widget:

Row(
  children: [
    Icon(Icons.person),
    Text('Person'),
  ],
)

Now TalkBack reads "Person" once, and the icon is not focusable. Screen readers don't "see" it.
In cases like that, you should usually merge the label and the text into one accessibility node. So the entire row becomes focusable. But it's not the topic of this part. You can read more about that in Part 1.

Pruning Subtrees with ExcludeSemantics

Take a standard contacts row: a CircleAvatar showing the first initial, and a Text with the full name beside it. Look at the code:

Row(
  children: [
    CircleAvatar(
      child: Text('A'),
    ),
    Text('Alice'),
  ],
)

And the video:

You haven't added any accessibility properties anywhere. But Text is always in the accessibility tree by default. The one inside the avatar too. TalkBack focuses on "capital A" first, then on "Alice." Announcing the initial doesn't make sense if there's a name right after it. For blind users it's noise.

The fix is to wrap ExcludeSemantics around the circle avatar. It removes the initial from the accessibility tree.

Row(
  children: [
    ExcludeSemantics(
      child: CircleAvatar(
        child: Text('A'),
      ),
    ),
    Text('Alice'),
  ],
)

Here's how it looks on a device:

TalkBack reads only "Alice." The same rule applies to any widget that generates semantic nodes you don't need — a decorative badge, a watermark, and so on.

In a real list you'd also wrap the row in MergeSemantics so the entire item becomes one node. That's already covered in Part 1.

There's also shorthand you may want to know about: Semantics(excludeSemantics: true). It excludes all children just like ExcludeSemantics. But it lets you set the semantic properties on the container itself. For example, you may add a label.

Blocking What's Behind: BlockSemantics

Flutter also provides BlockSemantics. It's for a different problem. ExcludeSemantics removes a subtree's own children from the accessibility tree. BlockSemantics hides sibling nodes rendered before it. Think of it as a semantic curtain — everything painted behind the BlockSemantics widget disappears from the screen reader's view.

Think of a custom loading overlay. You have a list of items, the user taps "Sync," and a semi-transparent scrim with a spinner appears. You built it with a Stack — no showDialog, no ModalBarrier. Without BlockSemantics, a screen reader user can still swipe through every list item underneath the scrim. They hear content they can't interact with. Not a good experience.

Here's how you do it:

Stack(
  children: [
    ListView(
      children: [
        ListTile(title: Text('Item 1')),
        ListTile(title: Text('Item 2')),
        ListTile(title: Text('Item 3')),
      ],
    ),
    BlockSemantics(
      child: Container(
        color: Colors.black54,
        alignment: Alignment.center,
        child: Semantics(
          label: 'Syncing',
          child: CircularProgressIndicator(),
        ),
      ),
    ),
  ],
)

BlockSemantics drops every sibling painted before it from the accessibility tree. TalkBack and VoiceOver only see "Syncing." The list items are not reachable by screen readers. Here's the screencast:

You won't need this for standard dialogs or bottom sheets. Flutter has a built-in ModalBarrier. It's out of the box in showDialog and showModalBottomSheet. The BlockSemantics widget also has a blocking property (defaults to true). You can change it dynamically if you need to turn the curtain on and off based on state.

Cross-platform Comparison

In SwiftUI, you can use .accessibilityHidden(true) to hide a view and its children from the accessibility tree. In Jetpack Compose, there is a clearAndSetSemantics { } for that.

Custom Semantic Actions — Giving Screen Readers a Gesture Vocabulary

A sighted user can perform a swipe gesture. A screen reader user can't do that. You have to provide alternatives to complex gestures — swipe-to-dismiss, long-press menus, drag-and-drop.

One of the simplest options is to add a custom action. You expose them with customSemanticsActions on the Semantics widget:

Semantics(
  customSemanticsActions: <CustomSemanticsAction, VoidCallback>{
    CustomSemanticsAction(label: 'Delete'): () {
      // TODO: delete the entry
    },
  },
  child: ListTile(
    title: Text('Item'),
  ),
)

Each CustomSemanticsAction gets a label and a callback. TalkBack presents these labels in its actions menu. It also announces that actions are available.
On Android, you can swipe up then down. On iOS, select "Actions" in the rotor, then swipe down. Look at the screencast:

Cross-platform: Custom Actions on Native

In Jetpack Compose, you can add custom actions through the semantics modifier and customActions property. In SwiftUI, you use .accessibilityAction(named:). All three frameworks follow the same idea of callbacks and labels.

Live Regions

Consider the following code snippet. It's a simple counter with increment and decrement buttons:

Row(
  children: [
    TextButton(
      onPressed: () => setState(() => _count--),
      child: Text('−'),
    ),
    Text('$_count'),
    TextButton(
      onPressed: () => setState(() => _count++),
      child: Text('+'),
    ),
  ],
)

At first glance, it looks fine. The buttons work. Screen readers announce: "Button, minus. Double-tap to activate," the number, and the plus button analogously.
If you can see the screen, you can watch the number change when you tap the buttons. But if you don't see anything, and you're using a screen reader only,
you don't know what the current value is. You need to move the accessibility focus back and forth between the buttons and the number to adjust the counter to the value you want.
Look at the screencast: ![Screencast of dynamic content without live region(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d1palf2hdo0btlyw1iq5.png)

It doesn't look like a good user experience. Fortunately, there's a solution. A live region. The concept comes from WAI-ARIA — an element that updates dynamically. Assistive technology announces it without the user moving focus there.

Flutter also supports live regions. To make a widget announce its value, wrap it in Semantics(liveRegion: true):

Row(
  children: [
    TextButton(
      onPressed: () => setState(() => _count--),
      child: Text('−'),
    ),
    Semantics(liveRegion: true, child: Text('$_count')),
    TextButton(
      onPressed: () => setState(() => _count++),
      child: Text('+'),
    ),
  ],
),

When _count changes and Text rebuilds, the app announces it. See it in action:

Look at the text of the first button. You may think it's a - that you can find on the standard keyboard next to the + key. Nothing could be further from the truth.
If it was -, a hyphen minus, screen readers would have announced it differently.
For example, TalkBack says "Dash":
And VoiceOver says "hyphen.":

Note that the exact results may vary depending on the screen reader (e.g., Samsung provides its own TalkBack) and the language. The correct character for a decrement button is a −, minus sign — a mathematical symbol.
The screen readers on both platforms announce it correctly as "minus." Note that string interpolation $_count isn't a good way to display numbers in the UI. You should use a NumberFormat instead. In the snippet, number formatting is omitted for brevity.

What You've Achieved

ExcludeSemantics removes redundant nodes from the accessibility tree. It applies to its entire subtree. BlockSemantics also removes nodes, but it targets siblings instead. customSemanticsActions gives screen reader users alternatives to gestures and other direct touch interactions. And Semantics(liveRegion: true) makes dynamic content announce itself when it changes.

In the next part you'll build a fully accessible custom widget from scratch — label, value, and actions. You'll also learn about semantic flags and roles. See you there!

Architecture Documentation as a First-Class Engineering Asset

Alexander Tyutin — Thu, 16 Apr 2026 09:49:24 +0000

How autonomous AI agents can generate a complete architecture snapshot of your microservices platform - while you do push-ups - and why that documentation becomes the most powerful input for your AI-driven quality pipeline.

You can listen a podcast generated based on this publication (thanks NotebookLM):

TL;DR

Architectural documentation is not a chore. When colocated with your source code and fed into an AI-powered quality pipeline, it transforms static analysis from "catching typos" into "catching systemic security failures and costly infrastructure leaks." This article documents a real experiment where an autonomous AI agent generated architecture files across a multi-service Google Cloud platform - with the human engineer largely off-screen - and what happened when that documentation gave our AI Quality Gate an entirely new perspective.

1. The "Self-Documenting Code" Problem

There is a persistent assumption in software engineering that well-structured code is self-explanatory. Clean functions, good variable names, and a Pylint score of 10.0/10 - surely that's enough?

It is not.

Code describes how a system executes. Architecture documentation describes why a system exists and how it interacts with everything around it. Without this context layer, every automated analysis tool is operating in the dark. It sees a function, but not its role in the broader service mesh. It sees an API call, but not the security boundary it is expected to enforce.

This distinction matters enormously when you introduce AI-powered tools into your engineering workflow. An LLM analyzing raw code without architectural context is like asking a senior engineer to perform a security review without access to the system design.

2. Generating Architecture While Doing Push-ups

My platform runs on Google Cloud. It consists of dozens of microservices deployed on Cloud Run, interacting via REST APIs, persisting assets to Google Cloud Storage, and routing all AI operations through a centralized Vertex AI gateway. A rich, well-connected system - but one where the only documentation was spread across scattered README files.

I set out to change that. The goal: a standardized, machine-readable architectural snapshot for every service, committed directly to the repository.

The method: guided autonomous agent execution.

The engineer set a direction, established the documentation standard, and then stepped back. The AI agent - powered by Gemini 3 Flash and Claude Sonnet 4.6 running inside Antigravity, an agentic AI coding assistant - took over. It autonomously inspected each service, read the source code, traced inter-service dependencies, cross-referenced existing implementations against the documentation standard, and iteratively generated structured ARCHITECTURE.md files. The engineer's main activity during most of this process was physical exercise.

The output was not informal notes. It was a disciplined, multi-level documentation hierarchy:

📦 platform-root
 ┣ 📜 ARCHITECTURE.md           ← Level 0: Global service mesh, topology, lifecycle status
 ┗ 📂 services
    ┣ 📂 core-ai-gateway
    ┃  ┗ 📜 ARCHITECTURE.md     ← Level 1: Security policy engine, FinOps guardrails
    ┣ 📂 orchestration-bot
    ┃  ┗ 📜 ARCHITECTURE.md     ← Level 1: Async task flow, Telegram webhook handling
    ┣ 📂 media-transcriber
    ┃  ┗ 📜 ARCHITECTURE.md     ← Level 1: Speech-to-Text pipeline, GCS asset management
    ┗ 📂 translation-engine
       ┗ 📜 ARCHITECTURE.md     ← Level 1: Structured output, multilingual routing

Each document followed a strict template:

Intent: The concrete business and technical reason this service exists.
Design Principles: Key trade-offs - statelessness, latency targets, fallback strategies.
Interaction Diagram: A Mermaid graph of service-to-service flows, security boundaries, and AI provider integrations. It may be generated by the agent and automatically drawn in Gitlab.
LLM Context Block: A precise summary optimized for consumption by automated agents and AI reviewers.

The entire operation resulted in a navigable, cross-linked architecture map - built with minimal human cognitive effort (and with visualizations!)

3. The Quality Gate Awakening

Once the documentation was committed alongside the source code, I ran a standard CI quality review using our AI-powered Quality Gate - a service built on top of Gemini via Vertex AI, designed to perform automated architectural and security reviews on every merge request.

💡 What is the Quality Gate, exactly?
It is not a $100,000 enterprise SaaS platform. It is a lightweight, purpose-built microservice - part of the same platform it reviews - deployed on Google Cloud Run. It exposes a single endpoint, receives the merge request diff from the CI pipeline, constructs an LLM prompt enriched with the repository's architectural documentation, calls Vertex AI (Gemini), and returns a structured JSON review report.

Because it runs on Cloud Run, it starts only when a review is triggered and shuts down immediately after. The total monthly cost for me is a few dollars - a fraction of a single human code review hour. This is a practical demonstration of the Google Cloud serverless model: pay only for the compute you actually use, and use high-intelligence AI only when it adds value.

The difference was immediately visible.

Previously, without architectural context, the Quality Gate was limited to code-level analysis: style consistency, common security anti-patterns, dependency versions. Useful, but shallow.

With the ARCHITECTURE.md files available as context, the model could see the architecture and the code simultaneously. The result was a qualitative leap: the Quality Gate shifted from a static analysis tool into a reasoning system operating at the level of system design.

It identified two critical issues within minutes - issues that had existed undetected in the codebase for months.

Finding 1: The Distributed Tracing Blackout

One of our routing services included middleware that explicitly stripped incoming trace headers. On the surface, this looked like a reasonable security measure to prevent external clients from injecting trace identifiers into internal systems.

The Quality Gate identified it as a critical observability violation.

Because the architectural documentation described the distributed tracing standard across the mesh - including the requirement for end-to-end X-Trace-ID propagation compatible with Google Cloud Trace - the model understood that stripping these headers at the boundary did not isolate a threat. It severed the trace chain entirely. In any production incident, engineers would be unable to correlate logs across services in Cloud Logging, turning a routine debugging session into a multi-hour forensic investigation with no Cloud Audit Logs correlation to lean on.

Security intention ✓. Systemic consequence ✗. The documentation made this contradiction visible.

Finding 2: The Silent Storage Leak

A media processing service was documented as intentionally skipping cleanup of temporary assets in Google Cloud Storage after each processing job. The rationale was implicit - simplicity, no failure modes from deletion errors.

The Quality Gate cross-referenced this against the documented architectural principle of data minimization and least-privilege access, and flagged it as both a security and FinOps violation.

The impact: user audio files - potentially containing sensitive personal information - accumulating indefinitely in cloud storage. No lifecycle policy. No deletion trigger. Silent, compounding cost growth. An expanding attack surface with each new processing request.

Neither a linter nor a code reviewer scanning functions in isolation would have flagged either of these. Both findings emerged from the intersection of code behavior and architectural intent - visible only because the documentation existed.

4. The ROI Case

This experiment produced a measurable return on investment across three dimensions:

Dimension	Without Documentation	With Documentation + AI Agent
Architecture Capture	Senior Architect hours	Agent cycle, near-zero human effort
Review Quality	Code-level findings	System-level and policy findings
Issue Discovery Cost	Post-incident or audit	CI/CD pipeline (minutes, pennies)
Quality Gate	Generic, rigid enterprise tool	Custom microservice, tunable per team or developer

Three additional factors are worth noting specifically in the context of Google Cloud platforms:

Vertex AI Token Efficiency: When the Quality Gate is backed by a Gemini model, providing a structured ARCHITECTURE.md reduces the tokens the model spends reconstructing system intent from raw code. Better context means cheaper, faster, and more accurate generation - directly impacting your AI compute costs.
Cloud Run Observability: The distributed tracing finding described above is particularly relevant for Cloud Run-based architectures, where services are stateless and ephemeral. Without continuous trace propagation, debugging inter-service failures on Cloud Run becomes significantly harder. The documentation made this risk explicit and catchable.
Serverless Cost Model: Because the Quality Gate is a Cloud Run service invoked only during CI/CD runs, there is zero idle cost. On a typical team with several merge requests per day, the entire AI-powered review pipeline costs a few dollars per month - less than a single engineering hour. This is the Google Cloud serverless model working exactly as intended: high-intelligence compute, on-demand, at minimal cost.

5. Lessons for Platform Engineers

The key insight from this experiment is not that AI agents write documentation faster than humans. That is expected. The key insight is that architecture documentation living inside the repository is a force multiplier for every automated tool that reads it.

This applies whether your automated tools are AI-powered code reviewers, compliance scanners, onboarding assistants, or infrastructure planning agents. The better the documentation, the higher the signal quality of every tool operating on top of it.

Practical recommendations:

Colocate documentation with code. A separate wiki that drifts out of sync is noise. An ARCHITECTURE.md in the service directory, updated in the same commit as the code, is signal.
Establish a documentation standard. A consistent template (Intent, Principles, Interaction Diagram) makes documentation machine-readable, not just human-readable.
Define a lifecycle status. Clearly mark deprecated or inactive services. Automated agents should not use legacy code as a reference for current standards.
Use agents to generate the initial draft. The cognitive overhead of starting from a blank page is real. Agents are excellent at producing a structured first pass that engineers then validate and refine.
Feed documentation to your CI pipeline. An AI quality reviewer with architectural context is a different class of tool than one without it.
Build your own Quality Gate - and make it yours. This is the key advantage that enterprise SaaS cannot match: flexibility. A custom Cloud Run service backed by Gemini and driven by your compliance rules, your architectural standards, and your team conventions means every developer can have a personal reviewer that understands the exact context of the project - not a generic ruleset designed for the average of all possible codebases.

6. Conclusion

Architecture documentation has historically been treated as optional overhead - valuable in theory, deprioritized in practice. This experiment demonstrates that when documentation is colocated with source code, follows a consistent machine-readable standard, and is kept current with the help of autonomous agents, it becomes a critical infrastructure component.

It enables automated systems to reason at the level of platform design, not just code syntax. It transforms AI-powered quality gates from expensive linters into genuine architectural advisors. And it can be generated - for an entire platform - while you are doing something else entirely.

The $10,000 ARCHITECTURE.md is not a metaphor. It is the estimated cost differential between finding a critical architectural flaw in a 5-minute CI review versus discovering it during a production incident, a compliance audit, or a cloud storage invoice that nobody expected.

Keep your architecture documented. Keep it in the repository. Let agents maintain it.

Stay standardized. Stay secure.

Using OpenCode as a fallback agent for Antigravity

Alexander Tyutin — Wed, 15 Apr 2026 10:45:53 +0000

Today I was confused by Antigravity errors about high load on their services. It made my work impossible even with the cheapest model Gemini 3 Flash.

Some time ago I heard something about the OpenCode. And it was the time to try it!

I've installed the opencode in my system by brew install anomalyco/tap/opencode and respective extension from the marketplace.

I have a good documentation inside the repo like described in the article Specification-First Agentic Development: A Methodology for Structured, Traceable AI-Assisted Development. So the default free OpenCode model Big Pickle performed planning, reviewing and coding stage well.

But then I realized that it was working without taking into the account system instruction and rules which I had for Antigravity.

So I've performed calls of Antigravity assurance workflows (like here and here) right from the OpenCode chat and it performed them perfectly.

As I have a lot of workflows for linting, security check of diff and the whole repo, and especially external self-made security gateway I was sure that the quality of code produced by the OpenCode was good enough and aligned with my codebase.

The only thing I can mention is a redundant file was left after some iterations of testing. But it can be fixed by a good review right after MR creation.

So seems the OpenCode is a good fallback for cases when Google servers are experiencing problems. Also it can by used to save tokens for some kind of tasks.

Gemini Thinking: How "Brainy" Models Unexpectedly Blew My Budget

Alexander Tyutin — Mon, 13 Apr 2026 07:29:03 +0000

Recently, Google notified me that the Gemini 2.0 models I was using are retiring. This was disappointing because my charity project for Technovation Girls, worked perfectly and very cheaply on those models.

I had to find a replacement. While Google recommended Gemini 3.0, those models are still in "preview". Since my project needs high stability, I chose the Gemini 2.5 family, which is already in "General Availability".

You can listen a podcast generated based on this publication (thanks NotebookLM):

The Surprise: Why is it so Slow and Expensive?

Switching was easy because I built my platform to handle model changes and fallbacks automatically. I simply updated my allowed models list and set gemini-2.5-flash-lite as the primary choice.

However, I was shocked by the results:

Requests took much longer to finish.
The quality was barely better.
Token usage exploded.
I saw a massive "system overhead" in my logs.

Before:

After:

The Cause: "Thinking" by Default

After digging into the documentation, I found the reason: all Gemini 2.5 models are "thinking" models. By default, they use as many tokens as possible to "reason" before answering.

My project worked great without this extra thinking. The slight quality boost was not worth the massive increase in latency and cost. I had to find a way to stop the model from thinking "on my dime".

The Technical Hurdle

I discovered that different models have different minimum "thinking budgets". Surprisingly, gemini-2.5-flash-lite has a higher minimum budget (512 tokens) than the more powerful gemini-2.5-flash (only 1 token!).

Model	Min Thinking Budget
Gemini 2.5 Flash Lite	512 tokens
Gemini 2.5 Flash	1 token
Gemini 2.5 Pro	128 tokens

To fix this, I had to expand my code to calculate and limit these budgets during fallbacks. I also had to handle the new text constants (MINIMAL, MEDIUM, HIGH) used by the Gemini 3.x models.

"gemini-2.5-flash-lite": {
           "model_page": f"{_MODEL_GEMINI_DOCS_BASE}/gemini/2-5-flash-lite",
           "is_thinking": True,
           "grounding_rag": True,
           "grounding_google_search": True,
           "count_tokens": True,
           "supports_thinking_level": False,
           "supports_thinking_budget": True,
           "min_thinking_budget": 512,
           "outputs": ["text"],
       },
"gemini-2.5-flash": {
           "model_page": f"{_MODEL_GEMINI_DOCS_BASE}/gemini/2-5-flash",
           "is_thinking": True,
           "grounding_rag": True,
           "grounding_google_search": True,
           "count_tokens": True,
           "supports_thinking_level": False,
           "supports_thinking_budget": True,
           "min_thinking_budget": 1,
           "outputs": ["text"],
       },
"gemini-2.5-pro": {
           "model_page": f"{_MODEL_GEMINI_DOCS_BASE}/gemini/2-5-pro",
           "is_thinking": True,
           "grounding_rag": True,
           "grounding_google_search": True,
           "count_tokens": True,
           "supports_thinking_level": False,
           "supports_thinking_budget": True,
           "min_thinking_budget": 128,
           "outputs": ["text"],
       },

The Result

I finally switched to gemini-2.5-flash with a strict limit of 50 thinking tokens.

Now, response speeds are back up and costs are back down. It was a lot of unexpected work for a "simple" upgrade, but everything is running smoothly again!

I tried to make DevFest Ireland accessible - and ended up building a SaaS

Jordan Harrison — Fri, 10 Apr 2026 13:18:59 +0000

The email I couldn't ignore

A few months into organising DevFest Ireland 2025, I received messages from a couple of deaf developers asking if they could attend.

Not in a vague "looks interesting" kind of way. They wanted to come. They wanted to sit in the talks, meet people, be part of it properly. And the question they asked was completely fair: would there be an Irish Sign Language interpreter?

I didn't have a solid answer for them at the time. I thought it would be one of those things that would take a bit of organising, a few emails, some budget approval, and then get sorted. That was my naive version of it anyway.

It turned out not to be like that at all.

Trying to make it work

Once I started looking properly, I ran into the shortage almost immediately. There simply are not enough ISL interpreters available, especially for full day events. Availability is tight, booking needs to happen early, and the logistics are harder than most people realise from the outside. For a conference, you are not just solving for one slot in a timetable. You are trying to cover a long day, with the practical reality that this kind of work cannot just be dumped onto one person and expected to somehow stretch across everything.

That was the point where it stopped feeling like a normal organiser task and started feeling like a structural problem.

The hardest part was that I now had real people waiting on an answer. I could not hide behind "we're looking into it" in my own head, because that still leaves someone wondering whether they can actually come.

It wasn't only about interpretation

The more I sat with it, the more obvious it became that this was bigger than one accessibility request.

Yes, ISL interpretation mattered. A lot. But so did transcription. And not only for deaf attendees. There are hard of hearing attendees who do not use sign language. There are people who find spoken content much easier to process when they can read along. There are neurodivergent attendees who benefit from seeing the words as well as hearing them. There are remote viewers. There are people trying to follow a technical talk delivered quickly by someone with a strong accent while half the room laughs at a reference they missed.

Once I started thinking about it that way, live transcription stopped feeling like a backup option. It felt central.

The options were not great

So I started talking to captioning and transcription providers.

The split was basically what you would expect, but more frustrating when you are the one making the call. Human captioning looked strong. High accuracy, experienced operators, something you could trust. But it came in at the kind of price that forces a community event to think very carefully about whether it can carry it.

AI captioning was somewhat easier to justify on cost - although it still ran into 4 figures(!) and the quoted level of accuracy just was not good enough for a technical conference. Not with fast speakers, different accents, library names, acronyms, product terms, and all the weird ways developers talk when they are explaining something they know too well.

That was the bit that kept bothering me. The choice seemed to be either spend a lot or accept something that would let people down. That is not much of a choice if the whole point is accessibility.

So I built it

At some stage, after enough comparing and researching and getting annoyed by the gap, I stopped asking who I should buy from and started asking what I actually wanted the software to do.

I wanted live transcription that could keep up with technical talks. I wanted something accurate enough that a person could depend on it instead of politely pretending it was helpful. I wanted it to be affordable enough that smaller events could realistically use it.

I was not thinking "this should be a SaaS." I was thinking "I need this to exist for DevFest."

So I built it.

It started the way a lot of things start: messy, practical, not especially glamorous. A lot of testing. A lot of fixing. A lot of checking the output and asking myself whether I would trust this if I were relying on it to follow a talk. That was the standard that mattered to me. Not whether it looked clever. Whether it actually helped.

From a solution for one event to VolenScribe

That tool eventually became VolenScribe.

VolenScribe is the SaaS that came out of all of this. It does live AI transcription for events, and it grew directly from trying to solve this problem in a way that did not feel half baked. One of the main things I cared about from the start was accuracy, because that is where so many AI transcription products fall apart once you put them in a real room with real people, and making sure it was useful beyond English-only events. VolenScribe supports 25 spoken languages, so it can be used across the world.

The AI transcription model used by VolenScribe has an average word error rate of 3.9%. That matters to me more than any vague claim about being smart or scalable or next generation or whatever else people like to say. The actual question is simpler: if someone is reading these captions, can they follow what is being said without constantly correcting the machine in their head?

That is the bar.

What actually mattered here

The strange thing is that I never set out to build a company around this. It came from a very specific problem, at a very specific event, because a few people asked a very reasonable question and I realised I did not have a good answer.

I think that is why this has stayed with me.

Accessibility is often talked about in broad, well-meaning terms, but the reality is much more direct than that. Someone wants to attend. Someone wants to follow the talk. Someone wants to feel like the event was built with them in mind too. Either they can, or they cannot.

That is what all of this came down to in the end.

Why I'm still thinking about it

I do not think organisers should have to choose between something expensive and something unreliable. I do not think accessibility should become one of those things people care about right up until the invoice lands. And I definitely do not think the answer should be "well, this is the best we could do" when the result still leaves people out.

Volenscribe started because I could not find something I trusted enough to use.

It just happened that solving that for DevFest Ireland 2025 turned into something other people needed too.

And really, it all goes back to those first messages. A few deaf developers reached out because they wanted to be there. Everything that came after, including the software, came from taking that seriously.

AI-Powered Repository Security Check with Antigravity Workflow

Alexander Tyutin — Mon, 06 Apr 2026 09:46:09 +0000

When teams want to "move fast and break things," security is often the first thing they forget. I've seen a lot over 15 years in the industry. My approach is simple: follow the Pareto Principle (80/20). You want 80% of the security results with just 20% of the work.

You can listen a podcast generated based on this publication (thanks NotebookLM):

In the AI era, that 20% of work can look like a single command.

Here is how we built the Antigravity workflow that checks the whole repository for security issues in several minutes. It does not cost much and does not use up all the AI's context window.

Short video demo made on a real repository:

The Initial Stack

To get a clear picture of a repository's health, one tool is not enough. We use a combination of proven, open-source scanners for the beginning:

Gitleaks: To find secrets like API keys and tokens.
Semgrep: For SCA and SAST to find bad code patterns and supply chain issues.
Checkov: To check IaC security (Docker, Terraform, Kubernetes).
OSV-Scanner: For SCA scan.

Inspecting their results manually takes a lot of time. And if you just send all their raw output directly to an AI, it becomes very expensive and confusing.

Token Economy

For a security review, the AI doesn't need to see every test that passed. It doesn't need to see the full abstract syntax tree. It only needs to know what is broken, where it is, and why it matters.

We use jq to remove the extra noise. This minifying step is very important for Token Economy.

To increase the token savings the command (workflow) may be ran with the cheapest Gemini 3 Flash. It is more than enough to receive a high-quality base report. Then the report may be reviewed with more powered models like Gemini 3.1 Pro.

Example: Minifying Results

Instead of a huge JSON file per tool, we make it small and simple. For example, here are the exact commands we use to make the results smaller:

  1. `jq '[.[] | {rule: .RuleID, file: .File, line: .StartLine}]' gitleaks-raw.json > gitleaks-min.json`
  2. `jq '[.results[] | {rule: .check_id, file: .path, line: .start.line, severity: .extra.severity}]' semgrep-raw.json > semgrep-min.json`
  3. `jq 'if type=="array" then map(.results.failed_checks[]) else .results.failed_checks end | [.[]? | {rule: .check_id, file: .file_path, line: .file_line_range}]' checkov-raw.json > checkov-min.json`
  4. `jq '[.results[]?.packages[]?.vulnerabilities[]? | {rule: .id, file: .package.name, line: "N/A", severity: ((.database_specific.severity) // "N/A")}]' osv-raw.json > osv-min.json`

By making the data 90% smaller, the AI stays focused on real problems. This makes the check much cheaper.

% ls -lh .security-artifacts | awk '{print $5, $9}'

6.3K checkov-min.json
2.6M checkov-rev-004-security-20260401-201110.json
2.4K gitleaks-min.json
19K gitleaks-rev-004-security-20260401-161824.json
19K gitleaks-rev-004-security-20260401-201110.json
107B osv-min-rev-001-security-20260406-110805.json
11K osv-raw-rev-001-security-20260406-110805.json
4.3K semgrep-min.json
61K semgrep-rev-004-security-20260401-161824.json
38K semgrep-rev-004-security-20260401-201110.json

The "One Command" Workflow

We put all these steps into one Antigravity slash command: /review-security-repo.

When we run it, the agent does exactly this:

Identifies the environment: Checks for tools like semgrep, gitleaks, checkov, osv-scanner and jq.
Executes Raw Scans: Runs the scanners to get raw logs.
Applies Minification: Uses jq to strip massive metadata.
Synthesizes Findings: Only reads the small files (gitleaks-min.json, semgrep-min.json, checkov-min.json, osv-min.json).
Performs Review: Checks high-risk files to find complex problems that static tools miss.
Generates an Actionable Report: Uses a strict Markdown structure instead of a generic summary.

Report Structure Snippet

The workflow forces the AI to output exactly what we need, like this:

### [Severity] - [Vulnerability Name/Rule ID]
- **Tool Source:** [Semgrep / Gitleaks / Checkov / Manual Architectural Review]
- **Location:** `[File Name]:[Line Number]`
- **Business Impact:** [Why this matters]
- **Remediation:** 
  [Actionable, copy-paste code or config fix]

Why This Works

Repeatability: Anyone on the team can check security without being an expert.
Audit Trail: Every raw and minified report is moved to .security-artifacts/ so we can track the history.
Reduced Hallucinations: Because we give AI only the exact scanner results and small code pieces, it gives real fixes without making things up.

Full Workflow Code

If you want to try this yourself, here is the complete code for the /review-security-repo workflow:

---
description: "Security review of the repo"
---

- Get the current branch name and current timestamp (format: YYYYMMDD-HHMMSS). Define output file as `security-review-[branch-name]-[timestamp].md`.
- Check for a `venv` (or `.venv`) directory in the repository root. If found, use its binaries.
- Verify if `semgrep`, `gitleaks`, `checkov`, and `jq` are installed. If missing, prompt for installation and pause until confirmed.
- Execute local security scanners to capture raw audit trails:
  1. `gitleaks detect --source . -v --report-format json --report-path gitleaks-raw.json`
  2. `semgrep scan --config auto --json --output semgrep-raw.json`
  3. `checkov -d . --quiet --skip-path venv -o json > checkov-raw.json`
  4. `osv-scanner -r . --format json > osv-raw.json || true`
- Execute `jq` to strip massive metadata, passed checks, and AST dumps, keeping only critical fields to save context tokens:
  1. `jq '[.[] | {rule: .RuleID, file: .File, line: .StartLine}]' gitleaks-raw.json > gitleaks-min.json`
  2. `jq '[.results[] | {rule: .check_id, file: .path, line: .start.line, severity: .extra.severity}]' semgrep-raw.json > semgrep-min.json`
  3. `jq 'if type=="array" then map(.results.failed_checks[]) else .results.failed_checks end | [.[]? | {rule: .check_id, file: .file_path, line: .file_line_range}]' checkov-raw.json > checkov-min.json`
  4. `jq '[.results[]?.packages[]?.vulnerabilities[]? | {rule: .id, file: .package.name, line: "N/A", severity: ((.database_specific.severity) // "N/A")}]' osv-raw.json > osv-min.json`
- Read ONLY `gitleaks-min.json`, `semgrep-min.json`, `checkov-min.json`, `osv-min.json`. Filter out false positives based on repository context.
- Analyze high-risk architectural files strictly for logical flaws and cross-service least-privilege violations that static tools cannot understand.
- Generate the report in `security-review-[branch-name]-[timestamp].md`. DO NOT output generic summary tables. You MUST output an exhaustive, itemized list.
- Use the following strict Markdown structure for the report:
  ## Executive Summary
  [Brief overview of the branch's security posture]
  ## Detailed Findings
  [Iterate through EVERY validated finding. For each finding, output:]
  ### [Severity] - [Vulnerability Name/Rule ID]
  - **Tool Source:** [Semgrep / Gitleaks / Checkov / Manual Architectural Review]
  - **Location:** `[File Name]:[Line Number]`
  - **Business Impact:** [Why this matters]
  - **Remediation:** 
    ```


    [Actionable, copy-paste code or config fix]


    ```
- Create a `.security-artifacts/` directory if it does not exist. Ensure `.security-artifacts/` is appended to `.gitignore`.
- Move and rename both raw and minified reports to `.security-artifacts/` to preserve the complete historical audit trail:
  - `gitleaks-raw.json` -> `.security-artifacts/gitleaks-raw-[branch-name]-[timestamp].json`
  - `semgrep-raw.json` -> `.security-artifacts/semgrep-raw-[branch-name]-[timestamp].json`
  - `checkov-raw.json` -> `.security-artifacts/checkov-raw-[branch-name]-[timestamp].json`
  - `osv-raw.json` -> `.security-artifacts/osv-raw-[branch-name]-[timestamp].json`
  - `gitleaks-min.json` -> `.security-artifacts/gitleaks-min-[branch-name]-[timestamp].json`
  - `semgrep-min.json` -> `.security-artifacts/semgrep-min-[branch-name]-[timestamp].json`
  - `checkov-min.json` -> `.security-artifacts/checkov-min-[branch-name]-[timestamp].json`
  - `osv-min.json` -> `.security-artifacts/osv-min-[branch-name]-[timestamp].json`
- Exit execution.

What’s Next?

What tools are missing from your perfect "One Command" security check? Will be happy to receive opinions on how to further optimize the token economy while expanding the security coverage.

Scaling Product Discovery: Orchestrating AI Agent Workflows with Google Opal

Sandro Moreira — Sun, 05 Apr 2026 14:52:06 +0000

Introduction: The Challenge of Relevance in Software Development

Developing an application is one thing; creating one that users actually want to use is another. The difference lies in the depth of your understanding of the pains, desires, and unmet needs of your target audience. Too often, development begins with a solution looking for a problem.

I recently embarked on a journey to optimize my product discovery process, moving from time-consuming manual methods to an AI-assisted application building workflow. My mission? To build a flow that not only generated ideas but deeply validated them against the real sentiment of the market.

The Flow

1 - The Raw Data Collection (Sources): I focused on a specific topic of interest and fed NotebookLM's source feature with complex data:

User Pains: Documents extracted from forums (Reddit, communities) to investigate pains unresolved by existing solutions.
Market Trends: Articles and research on emerging trends (e.g., generative AI integration, specialized niches).
Competitive Analysis: Detailed reviews and descriptions of competitor applications.

2- Information Cross-Referencing and Analysis: NotebookLM excelled at finding connections. By asking the model to cross-reference data, I could quickly identify patterns of complaints and resource gaps in the market.

3- Generating Strategic Insights (Prompts): I used structured analysis prompts to synthesize the data into actionable insights: "Cross-reference market trends with competitor features and identify a feature that is in high demand, but has low coverage in the market."

4 - The MVP Conception (Final Prompt): The final step was generating a highly refined MVP prompt, ready for development:
"Generate an MVP documentation (including Target Audience, Value Proposition, and 3 Essential Features) that addresses pain X, aligns with trend Y, and offers feature Z (low/non-existent coverage). The goal is for this MVP to be built on Gemini 3.0."

Scaling Discovery with Google Opal

The initial validation phase using NotebookLM was an insightful experiment, but it still required significant manual intervention. Now, it’s time to evolve this workflow into a truly automated engine.

This led me to Google Opal, the platform designed to turn complex logic into visual, multi-step AI Workflows (or mini-apps). While the concept mirrors the functionality of AI Agents - systems that take action autonomously - Opal provides the no-code workflow pipeline for orchestrating these steps reliably.

In Google Opal, the goal is to create a product discovery agent pipeline that operates continuously.

Step 1 - The Search: At external sources (forums, reviews) to filter and feed new pain signals and trends.

Step 2: The Analyst: Analyzes data from phase 1 against competitive data to generate strategic gaps and novel feature ideas.

Step 3: The Strategist: Converts the strategic report into the final assets for development and business.

Here is the step-by-step breakdown of how I configured the three core agents in Google Opal, turning a simple workflow into an autonomous pipeline.

Step 1: The Search (Data Ingestion)

This step is the system's eyes and ears, responsible for ingesting and pre-filtering raw market data.

1 - Topic of Interest: UserInput Initially empty node where the user enters the topic of interest.

2 - Search Users, Trends and Competitors: Generate Nodes for search with specific prompts

3 - Users Opinion, Trends and Competitors: OutPut (Google Docs)

Each output node I specified "Save to Google Docs" and set a name for the file in Advanced Settings.

Step 2: The Analyst (Insight Generation)

This is the brain of the operation, where raw data is turned into strategic intelligence.

1 - Analyze Problems: Generate

2 - Strategic Analysis: Generate

3 - Pain Points: OutPut (Google Docs)

4 - Strategic Analysis: OutPut (Google Docs)

Step 3: The Strategist (MVP & Pitch Generation)

The final takes the distilled strategy and turns it into deliverable assets for developers and stakeholders.

1 - Ideas App Generate

2 - MVP Recommendation Generate

3 - Generate Pitch Generate

The nodes are connected to other OutPut (Google Docs) (Ideas, MVP Recommendation) for creating files in Google Docs and the node Pitch has type OutPut (Google Slides)

And finally, the last step where we add a node to generate the Prompt for Gemini 3, another with an HTML output showing the result of the entire flow execution.

Conclusion: From Idea to MVP in Minutes

1 - Prompt to App: Generate

2 - Prompt for Gemini 3.0: OutPut (Google Docs)

3 - Generate HTML: OutPut (Manual Layout)

It transforms your workflow into an innovation pipeline quickly, ensuring that your next application not only meets a market need but is designed to address a real problem the market is actively complaining about.

By leveraging the power of agents and workdflows, we can move from market insight to a complete, validated, and ready-to-code MVP specification in minutes, significantly de-risking the development process.

opal.google

To create the MVP, simply use the generated prompt and run it in the Build tab of ai.dev, letting Gemini build it for you.

Want to put it into production? Use the icon in the upper corner of the built app screen to send it directly to Google Cloud.

Cross-Repository Development with Antigravity

Razan Fawwaz — Thu, 02 Apr 2026 02:26:20 +0000

If you've been sleeping on Antigravity, now's the time to wake up. Google's latest IDE isn't just another code editor — it comes with a built-in AI Agent Manager, meaning you can write code, run unit tests, spin up files, and execute everything directly, all while an AI assistant handles the heavy lifting alongside you. You can even plug in MCP Servers to pass richer context to the Agent.

Honestly? With Antigravity, you can kick off a task and go fishing. I'm not even joking.

The Problem with Scaling

Out of the box, Antigravity tends to scaffold projects using fullstack frameworks like Next.js or Vite + React. For smaller projects, that's totally fine — convenient, even.

But once you start scaling, a single monorepo starts to feel like a liability. The codebase bloats, separation of concerns gets blurry, and things that should be independent start bleeding into each other. Personally, I much prefer keeping frontend and backend as separate repositories. Shoutout to Kak Ishfa for pushing me to think about this more seriously.

Here's the catch though — Antigravity doesn't have a native Linked Workspace feature. There's no built-in way to point a single Agent at two separate repositories and have it work across both seamlessly.

But there's a workaround, and it's cleaner than you'd expect.

The Workaround: Agent Rules

The trick is using Agent Rules — a feature that lets you define behavior the Agent always follows, regardless of what you're asking it to do.

The idea is simple: open your frontend repository in Antigravity, then write a rule that tells the Agent about your backend repository's directory path. From that point on, whenever a frontend change requires a corresponding backend update, the Agent knows exactly where to go and what to touch.

Here's how I set it up: I have two repos, frontend and backend. In the frontend project, I added a rule that says — in plain language — "if any feature change requires backend work, update the backend repository too." The key detail is setting the activation mode to always on, so the Agent checks the rules on every single interaction, not just when you explicitly tell it to.

Here's a rough idea of what the rule content looks like:

You are working on a frontend project located at /path/to/frontend.
There is a paired backend project located at /path/to/backend (Go, net/http, SQLite).
Whenever a frontend change requires an API or backend change, apply those changes
to the backend project as well. Always keep both repositories in sync.

Simple, readable, and it works.

Putting It to the Test

To try this out, I built a todo app — login, full CRUD, connected to a Go + net/http + SQLite backend. Both directories started completely empty.

Once I submitted the prompt, Antigravity picked up the rules immediately and asked for approval before touching anything. After confirming, it installed the necessary packages and kicked off development — starting with the backend.

With the backend done, it seamlessly transitioned to the frontend and set up Vite + React.

When the chat stopped and the "accept all" button appeared, both projects were fully scaffolded and in sync — exactly as intended.

Wrapping Up

Is this the most elegant solution? Not really — ideally Antigravity would ship a proper Linked Workspace feature. But as a workaround, Agent Rules gets the job done surprisingly well. It's flexible, easy to set up, and once it's in place you barely have to think about it.

If you're working with separate repositories in Antigravity, give this a shot. It might just change how you build.

#Antigravity

Antigravity: My Approach to Deliver the Most Assured Value for the Least Money

Alexander Tyutin — Wed, 01 Apr 2026 05:49:34 +0000

As I'm not a professional developer but a guy who needs to use automation to get things done, I follow one main rule: keep it simple. Overengineering hurts. I use the Pareto rule—spend 20% of the effort to get 80% of the result.

When I use AI agents like Antigravity, my goal is not to let the AI write complex code that no one can read. My goal is to build simple, secure features fast. At the same time, I control costs by saving tokens. Here is the exact workflow I use.

You can listen a podcast generated based on this publication (thanks NotebookLM):

The Token Economy Strategy

LLM tokens cost money. Using a smart, expensive model just to fix code spaces is not worth the cost. I change models based on how hard the task is.

High-Tier Models: They are for the big tasks: planning architecture, writing complex business logic, checking security, and counting cloud costs.
Low-Tier Models: These folks are for simple tasks: fixing syntax errors, aligning code to Pylint, and writing standard code pieces.

Task Decomposition & In-Repo Architecture

Large prompts can break LLMs. If a prompt has too much text, the AI gets confused and wastes tokens. To stop this, I break every task into small, separate pieces so the AI only sees what it needs.

I store all architecture plans and tasks inside the code repository (for example, ./docs). This keeps the instructions very close to the code for the AI.

Every task I write uses this strict four-part structure:

Idea: The main business or tech goal. Why it matters: It proves the task is useful before I spend tokens for delivering a code to review.
Plan: The technical blueprint. Why it matters: It locks down the plan, keeps security high, and stops the AI from inventing bad solutions.
What Was Done: A short log of the work. Why it matters: It gives future AI tasks a quick summary, so the AI does not have to read every code file again.
Debt: A list of any technical shortcuts or "crutches" used to save time. Why it matters: Hidden debt ruins the project. Important: My custom Quality Gate checks this section. If it finds unapproved shortcuts in the code, it blocks the release completely.

System Instructions for the AI

To keep the AI agent aligned with the goals, I pass strict system instructions on every run. It never lets the model guess my coding standards. Here are the core rules enforced:

No Crutches: Any "crutch" or technical shortcut must be approved by me. Then, the AI must document it as technical debt in the project files.
No Inventing Wheels: I try hard to avoid this. If a working approach already exists in another project, the AI reuses it.
Learn from the Past: When building a new service, the AI must check the old tech debt to avoid repeating past mistakes.
Simple Code Only: The code structure should just use standard classes. I avoid "genius-level" extreme one-line code tricks or overwhelming structures.
Maintainability First: A middle-level, part-time developer must be able to read and maintain the code.

The Core Workflow

Every feature goes through a step-by-step process. I'm trying to keep security and simplicity as the main focus at each step.

1. Plan & The Plan Review

Using a High-Tier Model.

Plan: Defining the code structure, the security rules, the cost limits, etc. I make sure not to add to old technical debt.
Review: I look at the plan with a "fresh eye." I do not start coding until the plan is clear with main code snippets planned.

2. Code & Code Review

Using a Low or Mid-Tier Model for code and Mid or High-Tier Model for review.

Code: Implement the code exactly as planned. Use clear classes and avoid complex, one-line code tricks. A middle-level developer must be able to maintain it easily.
Review: Make sure the code matches the rest of the project. I prefer another "person" to check it before I call it done.

3. Lint & Quality Gate

Using Free External Tools & A Custom Nanoservice.

Lint: I do not pay LLMs to fix missing spaces. I use free tools like autopep8, ruff, and pylint to save tokens.
Quality Gate: I built a simple nanoservice using the Vertex API. It checks the code changes against the main branch. It works like an automatic review from the CTO, CISO, and CFO. It checks every line for good architecture, proper security access, and cost impact before the code goes to production. Why is it so important? The Quality Gate is not overwhelmed by the full chat history inside the IDE. Its "fresh eye" often finds architectural and coding flaws that were missed by the IDE models, even after 6 to 9 rounds of review.

The Bottom Line

AI coding is not magic. In my experience, it requires a strict testing gate, smart model swapping, and simple design. By owning the process and letting the AI act as a typist, it is possible to ship secure code fast. I share this approach for an open discussion on how we can build better automation.