标签：#ev

Hey DEV community! 👋 When debugging network streams, parsing custom file formats, or inspecting database buffers, we often extract data as raw arrays of numbers rather than human-readable text. This data typically presents itself as raw byte sequences formatted in either decimal or hexadecimal notation. While there are online decoders available, pasting raw byte sequences into third-party sites that process data on their backend databases introduces an unnecessary data privacy risk. To solve this, I designed a lightweight, entirely browser-based Byte to String Converter that decodes raw byte sequences locally using standard JavaScript APIs. In this post, we will look at how bytes map to character encodings and implement a client-side JavaScript utility to decode them safely. The Structure of a Byte In modern computing, a byte is the basic unit of digital information, consisting of an 8-bit sequence: 1 byte = 8 bits Because each bit represents a binary state (0 or 1), a single byte can represent: 2 8 = 256 states This translates to numeric values spanning from: Decimal (Base 10): Range of [ 0 , 255 ] Hexadecimal (Base 16): Range of [ 00 , FF ] When we render characters on a screen, we rely on character encoding tables (such as ASCII or UTF-8) to map these numerical byte values back to their original symbolic representations. Navigating Encodings: ASCII vs. UTF-8 The reconstruction process depends entirely on the encoding format used: ASCII: A basic 7-bit standard where each character maps to exactly one byte. It covers basic English letters, numbers, and core control characters. For example, the decimal value 72 maps to the uppercase letter 'H' . UTF-8: A variable-length encoding format that utilizes between 1 and 4 bytes per character. This structure allows UTF-8 to represent emojis, mathematical notations, and diverse language scripts. Our browser utility parses byte sequences using UTF-8 to maintain compatibility with modern web standards. JavaScript Implementatio

We finally added OTA updates to Romi. This is something apps have been doing for years, but it’s new territory for us. Instead of waiting for Apple’s review every time we need to push a small fix, we can now ship certain updates directly to users. And because apparently paying for another service wasn’t exciting enough, we built our own setup using Capgo + CDN. It’s one of those things that feels obvious once it works. Getting there was slightly less obvious. 😅 What’s something your team implemented way later than everyone else?

I’ve been building Unmuse because I kept noticing a simple problem: Having an idea is easy. Turning that idea into something actually worth posting is the hard part. You can have a thought like: “People keep waiting for the perfect time to start.” But turning that rough thought into a strong hook, script, or caption can take way more effort than it should. So I built Unmuse. You give it the rough thought in your head, choose what you want to create, and Unmuse turns it into a usable piece of content. Right now, it’s an early MVP. I’m building it mostly by myself and plan to add a lot more features as I get feedback and traction. If you create content, I'd genuinely love to hear: What’s the most annoying part of turning an idea into a post? Try it here: https://unmuse.online/

There’s a funny (and slightly sad) story behind why I built mabims.dev . It started with a date. More specifically, a Hijri date . Once Upon a Time, the Government Website Had the Date For a long time, Indonesia’s Ministry of Religious Affairs (Kemenag) website displayed the current Hijri date. It was convenient. You opened the website, looked at the corner of the page, and there it was: Today: 30 Sha'ban Simple enough. A lot of people, including me, got used to relying on it. Then one day, something weird happened. A post went viral. Someone noticed that the official calendar published by Kemenag said one date , while the date displayed on Kemenag’s own website said the next day . They were off by one day. People started asking: How can the official website and the official calendar disagree with each other? The post spread. People discussed it. And then… The Solution? Just Delete It. I didn't know what exactly happened behind the scenes. Maybe it was a bug. Maybe it was a calculation issue. Maybe the website was using a different data source. I don't know. But I do remember what happened eventually. The Hijri date disappeared from the website. Problem solved. Technically. If you can't display the wrong date, you can't display a wrong date. Elegant. 😂 At the time, I just thought it was funny. A few years later, I became a developer. And suddenly, the story made a lot more sense. Years Later, I Became a Junior Developer Once I started working as a developer, I learned how easy it is to add a Hijri date to a website. You don't need to calculate the lunar calendar yourself. You just install a library. Or call an API. There are plenty of them. The problem is that most of the libraries and APIs you'll find use Umm al-Qura by default. And that's perfectly reasonable. Umm al-Qura is the official calendar of Saudi Arabia. It's well documented, widely supported, and easy to integrate. For a developer who just wants: Gregorian date → Hijri date it works great. But there's a

A GitHub Copilot spending limit is a monthly budget, set in billing settings, that caps metered AI credit consumption for an enterprise, an organization, a cost center, or a single user. Creating one takes about two minutes. Knowing what it stops takes longer, and the gap between those two things is where most surprise Copilot invoices live. Two facts account for nearly all of them. On enterprise, organization and cost center budgets, the setting that actually blocks usage is off by default, so a budget in its default state is an alert rather than a limit. And no budget of any kind caps seat cost, because seats are license-based rather than metered. A spending limit governs what happens after the included credit pool runs out, and nothing before it. How to set a GitHub Copilot spending limit Budgets live in the billing settings of the account that pays. Enterprise owners and billing managers can set every budget control, including enterprise, cost center and user-level budgets. Organization owners can set a budget for their own organization, and that budget can only restrict usage further below whatever an enterprise admin has already set. It cannot raise the ceiling. The mechanics are the same at every level. Choose the budget type, which determines the metered product being measured. Choose the scope, which determines whose usage counts against it. Enter a monthly amount. Then, if the option appears, enable Stop usage when budget limit is reached and switch on threshold alerts at 75, 90 and 100 percent. That single checkbox is the whole exercise. Skip it and you have built a notification. What a GitHub Copilot spending limit actually caps GitHub splits its products into license-based and metered. For license-based products, which include Copilot seats, setting a budget does not prevent usage above the amount. It only alerts. For metered products, which include Copilot AI credits, a budget can prevent usage once the threshold is reached. The consequence is worth st

If you searched for a klogg alternative , you probably already know klogg is good. It is fast, it is free, it is open source, and it runs on Windows, macOS and Linux. Most people who go looking for something else are not unhappy with klogg as a viewer. They are unhappy with one specific moment in their day: Opening the file again. You investigated a 48GB log yesterday. You closed it. This morning your colleague asks about a different error, and you have to wait through the whole index build a second time. On a USB HDD that is nine minutes of staring at a progress bar — and while it builds, klogg only shows you the beginning of the file. That is the problem this article is about. Below is a measured comparison on a real 47.73GB file, including the rows where klogg wins . The test File OpenStreetMap Japan japan-latest.osm — 47.73 GB, 892,239,125 lines Machine MacBook Air / Apple M4 (10 cores) / 32GB RAM Storage (measured with dd ) USB HDD 0.10 GB/s ／ USB SSD 0.41 GB/s ／ Internal SSD 3.29 GB/s Versions klogg 24.11.0 ／ UwView Pro Search hit counts were verified to match exactly across klogg, UwView Pro, and a direct search of the raw file — so we know both tools are answering the same question. The numbers klogg 24.11.0 UwView Pro Ratio First open HDD ~9 min ／ USB SSD ~110 s ／ Internal SSD ~15 s — every time HDD 10.6 min ／ USB SSD 138.5 s ／ Internal SSD 23.3 s — first time only klogg wins Reopening Same as the first open (re-indexes every time) 0.01–0.07 s ~1,250–50,000x Search, literal "Tokyo" ~585 s ／ 120–135 s ／ 15–20 s 74.8 s ／ 14.3 s ／ 5.1 s ~7.8x ／ ~9x ／ 3–4x Search, regex "Tok[yi]o" ≈ literal (I/O bound, pattern-independent) 29.8 s (USB SSD) ／ 11.0 s (Internal SSD) ~4.4x ／ ~1.5x Disk used to keep the file 48 GB (original required) 5.3 GB (original can be deleted) 1/9 Two things are worth saying plainly. klogg opens the file faster the first time. UwView Pro is slower on the first open because it is building a compressed cache while it reads. That is a real cost a

LINE published an official MCP server for its Messaging API, which means an AI agent can now drive a LINE Official Account directly — sending messages, broadcasting promotions, and pushing Flex Message cards without writing any API code. I set it up with Codex and worked through every capability the server exposes, from creating a fresh account to delivering a message to a real phone. This guide is the result: a complete walkthrough, and an honest account of the three places where the documentation and reality diverge. Key takeaways MCP is agent-agnostic. The same LINE server works with Codex, Claude Desktop, and Cline — only the config file format changes, from TOML to JSON. Codex stores MCP config in TOML , at ~/.codex/config.toml . Most guides assume the JSON format used by Claude Desktop, which is the single most common setup mistake. Verified account and API-capable account are different things. A free account can use the Messaging API, but get_follower_ids returns 403 Forbidden until the account is verified or on a premium plan. Official security advice can conflict with official features. LINE's example config disables npm install scripts, which also prevents the headless browser that the rich menu tool depends on from being installed. Agents have habits. Codex is a coding agent first: asked in natural language to build a rich menu, it wrote a Node script instead of calling the MCP tool. Naming the tool explicitly in the prompt fixes it. Broadcasts cannot be recalled. Set default_tools_approval_mode = "writes" so the agent asks before any send. Every screenshot comes from the actual working setup, including the errors. The article is available in both English and Thai. Devlycan - Technology & Programming Insights Devlycan - Technology, programming, AI, lifestyle, and future trends—simple insights for the new digital generation. devlycan.com

Building Next-Gen Agentic Architectures: From Local RAG to Sandboxed Execution and BigQuery MCP The 3 AM production fire revealed a harsh truth: modern agentic systems often collapse under their own weight. A single agent processing 10K RAG queries OOM-killed an 8GB cloud instance. The culprit was not the workload but the infrastructure: @pinecone-client/vecdb with 47 transitive dependencies bloat memory with unquantized float32 embeddings. The solution was 200 lines of Python using sqlite3 , array , and heapq , with bounded queues and race condition resilience. This is the story of how we replaced dependency bloat with surgical precision. The Dependency Problem Agentic systems today face three critical bottlenecks: Vector Search : Libraries like faiss-cpu (12MB) combined with pg-vector (synchronous disk I/O) block the event loop, creating latency spikes. BigQuery : The @google-cloud/bigquery client (12MB) plus grpcio (5MB) leaks file descriptors, hitting Linux's default 1024 soft limit. Sandboxing : Docker containers consume 500MB+ per instance, making them impractical for memory-constrained environments. The root cause is always the same: unbounded resource consumption. 1M vectors at 768 dimensions in float32 consumes 3GB of memory. Synchronous I/O stalls the event loop. Unmanaged connections leak file descriptors. The Zero-Bloat RAG Engine The solution begins with a fundamental shift: replace heavy dependencies with lightweight, audited code. Our LocalRAG implementation demonstrates this approach: import sqlite3 import array import heapq import json import threading from typing import List , Tuple , Optional class LocalRAG : def __init__ ( self , db_path : str , dim : int = 768 , max_vectors : int = 1_000_000 ): self . dim = dim self . max_vectors = max_vectors self . lock = threading . Lock () self . conn = sqlite3 . connect ( db_path , isolation_level = None , check_same_thread = False ) # Enable WAL mode for concurrent reads/writes self . conn . execute ( " PR

I did not start building MSG.AI because I had discovered a grand new AI opportunity. It began with a much smaller problem—one that kept repeating every day. A message arrives in another language. You copy it into a translation tool, read the result, write a reply, translate that reply, and paste it back into WhatsApp. When a customer asks a familiar question, you search through a document or an old chat for the answer you used last time. Each step takes only a few seconds. None of them looks important enough to justify a new product. But when someone handles dozens of international conversations a day, those small interruptions fragment the entire workflow. That was the starting point for MSG.AI. Why a browser extension instead of another support platform? My first instinct was to build a standalone web application with its own inbox, contacts, translation tools, and customer management features. I abandoned that direction fairly quickly. People were already working inside WhatsApp. Asking them to adopt another inbox meant another login, another data sync, and another interface to keep open. The product might have looked more complete, but it would also have introduced the exact kind of context switching I was trying to remove. A browser extension offered a simpler approach: leave the conversation where it already lives and add the missing tools around it. Customers remain in the existing chat list. Messages still go through the current WhatsApp Web session. The extension handles supporting tasks such as translation, reusable replies, controlled messaging tasks, and exports. I think of it as adding a small workbench next to the desk people already use—not asking them to move into a new office. Bulk messaging came first, but translation became more important The earliest version focused mostly on sending customer updates in batches. There are legitimate reasons to notify a group of existing customers: order updates, delivery notices, holiday schedules, missing docume

When people see a browser extension add translation controls, a side panel, or a sending workflow to WhatsApp Web, a common question is: how does the extension actually interact with the page? The short answer is that a modern Chrome extension is split across several execution environments. No single script should be responsible for the interface, persistent state, task scheduling, and access to the page at the same time. This article explains the architecture at a practical level without depending on private implementation details that may change whenever WhatsApp Web changes. A browser extension does not run as one program The simplest mental model is to divide the extension into four parts: The extension interface A background service worker A content script attached to WhatsApp Web A small bridge running in the page's own JavaScript context Each part has a different job and a different level of access. The extension interface is what the user sees: forms, task history, translation settings, saved scripts, and media selection. It should focus on interaction rather than long-running work. The background service worker coordinates tasks and stores state. It can receive a request from the interface, keep track of progress, and send commands to the correct WhatsApp Web tab. The content script lives alongside the webpage. It can inspect the rendered document, inject controls, and communicate with the extension runtime. Chrome isolates it from the page's own JavaScript environment for security. The page bridge exists because isolation is sometimes a limitation. A content script can see the DOM, but it does not automatically share the same JavaScript objects as WhatsApp Web. When deeper page integration is required, a carefully scoped bridge can exchange explicit messages between the isolated extension world and the page world. Why not put everything in the content script? It is tempting to keep the entire feature in one file because the content script is already attach

The atmosphere in the room was dense, the kind where every whisper echoes. I was sitting in the third row of a local community center during a Friday prayer session, my head bowed in reflection. Suddenly, a high-pitched, synthetic ringtone shattered the silence. My pocket vibrated violently, sending a jolt of anxiety through my chest. I scrambled to silence it, but the damage was done; a dozen heads turned in my direction. I wasn't just embarrassed; I was frustrated with myself for the thousandth time for forgetting the simple task of toggling a silent switch. This wasn't an isolated incident. I found myself constantly caught in a cycle of human error. I would arrive at the office, launch into a deep-work sprint, and realize two hours later that my phone had been chirping with notifications through three separate meetings. Then, I would leave the office and forget to turn the ringer back on, missing urgent calls from family throughout the evening. The friction wasn't in the hardware; it was in the expectation that a human should perfectly manage a state machine that they interact with hundreds of times a day. I realized that my phone was intelligent enough to track my location, calculate prayer times, and sync my schedule, yet it remained stubbornly passive regarding its own audio profile. Most existing automation tools were either too heavy, draining the battery within hours, or relied on cloud-based triggers that failed the moment I lost signal. I wanted something that lived on the device, respected the user's privacy, and handled the transition between 'Silent', 'Vibrate', and 'Normal' states without me ever needing to touch the screen. The goal was simple: build a background service that watches the world and adjusts the phone's volume automatically. I needed an architecture that could handle geofencing, calendar events, and time-based triggers without turning the device into a space heater. When I started building the geofencing engine for Muffle, the immediate

Winning is the part everyone posts about. The two months after — the part where a cash prize actually...

It's conference season! I already had to sit at home jealous while friends had fun at Render ATL, but it's my turn soon with Commit Your Code next week in Plano, TX. It boasts a banger lineup of speakers, which got me thinking: how do you get the absolute most out of an event like this? The number one rule is determining your goal before you step through the doors. Are you going to hang out with friends, meet new people, or hunt for a job? Each objective requires a completely different approach, prep strategy, and attire. 1. Hanging Out with Friends This is the easiest path. Wear whatever keeps you comfortable while looking relatively professional. Meet up with your crew, enjoy the sessions, and have fun. You done did it. 2. Networking and Meeting New People This is my primary goal for CYC this year. I'll fill you in on my plan. To keep from getting overwhelmed, I built a tracking spreadsheet for everyone I want to connect with. It might sound clinical, but it ensures no follow-up slips through the cracks. Here is my process: Pre-Conference Research: First, I reviewed the talk schedule and logged the speakers and session titles that caught my eye. Initial Outreach: I added columns for sending an intro message and a LinkedIn connection request. Then I sat down and message every single one of them. I had a bit of a template, but mostly just told people why their talk sounded interesting or exciting to me. It's hard to have writers block when you have a genuine interest in something. Some of them replied, some didn't, but I already feel like I have a foot in the door heading into the conference. During & After the Event: My spreadsheet includes columns for attending their talk, taking photos (speakers always need good photos of themselves on stage), posting on social media, and sending a post-event follow-up. Sounds like a lot? Because it is! Which is why its in a spreadsheet and not my pasta strainer brain. But it's about intent, respect, and appreciating someone else

AI coding agents are getting very good at writing code. They can build components, create APIs, fix bugs, and implement features from short prompts. But I kept noticing one issue: Working code does not always mean a good product. For example, if you ask an agent: “Add a delete button to every project.” It may technically do exactly that. But will it also think about: confirmation before deletion error handling undo options accessibility clear feedback to the user Those are not just coding problems. They are product judgment problems. That led me to experiment with a reusable instruction layer for AI coding agents at AudranLab. The idea is simple: Instead of only asking an agent, “Can you build this?”, also encourage it to ask, “Is this a good way to build it?” I want agents to consider things like accessibility, failure states, destructive actions, usability, and sensible defaults while they work. This does not magically turn an AI into a product designer. But I think it raises an interesting question: Can explicit product principles consistently improve the quality of software generated by coding agents? That is what I’m currently exploring. My next step is to test the approach across different coding tasks and compare the results with and without the additional product-judgment layer. If you’re interested in AI agents, LLM reliability, developer tools, or applied AI, I’ll be sharing more experiments here. AudranLab: https://www.audrantechlab.online/

Welcome to the fifth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Today we discuss why "we already use HTTPS" isn't a sufficient answer. Introduction M5 is the most misleading item on the list, because most teams read it and move on: "We use HTTPS, this doesn't apply to us." OWASP's definition is far broader. This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. It includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc. So M5 isn't just "do you use HTTPS." It's all of this: Whether you set up TLS correctly (certificate checking, cipher selection) Whether your traffic is consistent (some endpoints HTTPS, others not) What your third-party SDKs are doing What your WebView is loading What you send over alternate channels like push notifications and SMS 💡 Key point: Just because an app uses transport security protocols doesn't mean it's implemented correctly. HTTPS is not a checkbox; it's a system that must be configured properly. A specific situation for React Native developers In React Native the network layer lives in three separate places, and most developers only think about the first: The JavaScript side — fetch , axios , XMLHttpRequest Platform configuration — ATS on iOS, Network Security Config on Android Native modules and SDKs — analytics, ads, crash reporting, payment SDKs Whatever you do on the JavaScript side, if platform configuration is loose or a third-party SDK uses plaintext HTTP, your app is exposed. OWASP Assessment Metric Value Meaning Exploitability EASY A proxy and the same network is enough Prevalence CO

Un déploiement devrait être la chose la plus ennuyeuse de ta semaine. S'il est excitant, c'est mauvais signe. Au début de ma carrière, les mises en production étaient des événements. On retenait son souffle, on croisait les doigts, quelqu'un exécutait de mémoire une séquence d'étapes manuelles, et on regardait les journaux avec une boule au ventre. C'était palpitant. C'était aussi terrifiant, et le côté palpitant était précisément le problème : chaque déploiement était un pari, parce que chaque déploiement était un peu différent du précédent. Un bon déploiement est répétable. La même chose, de la même façon, à chaque fois — automatisée, pas récitée par un humain fatigué à la fin d'une longue journée. Quand le processus est un script plutôt qu'une cérémonie, l'ennui remplace l'angoisse. Tu ne pries plus. Tu appuies sur un bouton, et le résultat est prévisible parce qu'il a déjà été prévisible cent fois. L'automatisation fait ici plus que gagner du temps. Elle supprime toute une catégorie d'erreurs : l'étape oubliée, le mauvais paramètre, le « je croyais que tu l'avais fait ». La machine ne se fatigue pas, ne saute pas de ligne, ne se laisse pas distraire à mi-chemin. Elle rend le déploiement fiable au point d'en être ennuyeux — et l'ennui, en production, est un luxe. Alors, si tes mises en production font encore monter le rythme cardiaque, ce n'est pas de la prudence. C'est un signal. Rends-les répétables, rends-les automatiques, rends-les ennuyeuses. Garde le frisson pour ta vie ; ton système de production, lui, mérite l'ennui. – Serguey Shinder

Caricare un’estensione da disco, aprirne il popup e automatizzare verifiche UI: un workflow più completo per chi sviluppa estensioni e usa agenti. Sviluppare un’estensione Chrome oggi significa spesso alternare tre modalità: codice “a mano”, generazione assistita da un coding agent e una fase di verifica nel browser che resta comunque imprescindibile. Il problema è che molti agenti riescono ad aprire pagine e cliccare elementi, ma si fermano quando entrano in gioco le estensioni: installazione, gestione del popup, interazioni con la UI dell’estensione, verifica rapida dei cambiamenti. Chrome DevTools for agents colma proprio quel vuoto: aggiunge al set di strumenti dell’agente la possibilità di installare e pilotare un’estensione durante i test, oltre a renderne più pratico il debugging. Quando è davvero utile Ci sono alcuni scenari tipici in cui il supporto “estensioni-aware” fa la differenza: Ciclo di feedback più rapido : compili/packi l’estensione, la carichi in Chrome e verifichi subito il popup o una content script UI. Test end-to-end più realistici : invece di simulare una UI in una pagina fittizia, testi l’estensione nel suo contesto reale (action popup, permessi, storage, ecc.). Validazione automatizzata : l’agente può controllare che l’estensione si installi correttamente, che il popup si apra e che i componenti principali siano presenti e interagibili. In pratica: se il tuo agente sa “guidare” il browser ma non sa “gestire” le estensioni, la qualità del test rimane limitata. Setup: abilitare esplicitamente gli strumenti per le estensioni Un dettaglio importante: per ragioni di sicurezza e controllo (in particolare per l’uso dei token e del contesto in cui operano gli agenti), le funzionalità specifiche per estensioni non sono abilitate di default . Dopo aver installato Chrome DevTools for agents, serve quindi un passaggio esplicito nella configurazione MCP: individua il tuo file di configurazione MCP ; abilita la categoria dedicata alle estensioni aggiung

On ne gère pas ce qu'on ne mesure pas. C'est l'une des premières leçons de l'exploitation, et pourtant je l'ai apprise à l'envers, en pilotant à l'aveugle bien trop longtemps. Sans mesure, tu ne sais pas si un système va bien. Tu le supposes. Il tourne, personne ne se plaint, donc tout va bien — jusqu'au jour où quelque chose se dégrade lentement, sous le radar, et où tu ne l'apprends que lorsque c'est déjà une panne. La lente fuite de mémoire, le disque qui se remplit, la latence qui grimpe d'une milliseconde par semaine : rien de tout cela ne crie. Ça glisse. La mesure transforme les suppositions en faits. Un tableau de bord, quelques alertes bien choisies, et soudain tu vois le problème arriver au lieu de le subir. Tu n'attends plus que l'utilisateur t'apprenne que ton système est cassé ; tu le sais avant lui. Mais il y a un piège que j'ai appris à éviter : mesurer trop. Cent métriques que personne ne regarde ne valent pas mieux que zéro. Le bruit noie le signal, et les alertes qui se déclenchent sans raison finissent par être ignorées — jusqu'à celle qui comptait vraiment. Bien mesurer, ce n'est pas tout mesurer. C'est choisir les quelques signaux qui prédisent réellement un problème. Alors, avant de bâtir la prochaine chose, demande-toi comment tu sauras si elle va mal. Si la réponse est « quelqu'un finira par le remarquer », tu ne la gères pas encore. Tu espères. Et l'espoir n'est pas une stratégie d'exploitation. – Serguey Shinder

Alle paar Jahre verkündet jemand, dass die IT-Jobs verschwinden. Die Cloud ersetzt die Administratoren. Die Automatisierung ersetzt die Operatoren. Jetzt ersetzt die KI, was übrig ist. Und alle paar Jahre verschwinden die Jobs nicht, sie wandern. Sie wandern den Stack hinauf. Als physische Server der Cloud wichen, brauchten wir keine Infrastruktur-Leute weniger, wir brauchten Menschen, die Infrastruktur auf einer höheren Ebene verstehen, die Systeme entwerfen, absichern und kostenbewusst betreiben, statt Hardware in Racks zu schrauben. Als manuelle Deployments der Automatisierung wichen, brauchten wir Menschen, die die Automatisierung selbst bauen konnten. Jede Welle entfernte nicht die Arbeit. Sie hob den Boden und verschob den wertvollen Teil nach oben. Die KI ist die nächste Welle, und ich erwarte, dass sie sich genauso verhält. Sie wird viel Routine aufsaugen: das Skripten, die ersten Config-Entwürfe, die Standard-Fehlersuche. Was sie nicht aufsaugt, ist Urteilsvermögen: zu wissen, was zu bauen ist, zu entscheiden, was das Risiko wert ist, zu verstehen, wie die Teile einer echten Organisation zusammenpassen, und geradezustehen, wenn etwas schiefgeht. Wer in jedem Übergang strauchelt, sind die, die sich über die Aufgabe definieren, die automatisiert wurde. Wer gedeiht, definiert sich über das Problem, das er löst, und lässt die Werkzeuge dafür sich darunter ändern. Verteidige also nicht das eine, das du heute tust. Werde gut in der Schicht darüber. Der IT-Job hat jedes Werkzeug überlebt, das ihn beenden sollte, indem er den Stack hinaufwanderte. Diesen wird er genauso überleben. – Serguey Shinder

Previously I have a macOS App I use myself, gemini-live-translate-macos . It uses ScreenCaptureKit to directly capture audio from a specified App, eliminating the need for virtual sound cards like BlackHole. It then sends the audio to the Gemini Live API for real-time translation, outputting Traditional Chinese subtitles while playing Chinese audio. I've written two posts about the development process: the first one was about building it from scratch using AGY CLI, and the second one was about using Claude Code to take it from "functional" to "user-friendly." The starting point for this new addition was simple: I saw a document for "Real-time Transcription" added to the Live API. Since I was already connected to the Live API, I thought adding a pure transcription mode would just be a matter of changing a few parameters. However, after checking the documentation, I realized that Google released two models with very similar names but very different capabilities at once. The specific feature I actually wanted (speaker diarization) wasn't available at all on the model I originally thought it was. Two Models with Names Differing by Only Two Words Let's lay out the differences first; this is the part I spent the most time figuring out: gemini-3.5-transcribe-live gemini-3.5-transcribe API Used Live API (WebSocket streaming) Interactions API (Standard HTTP request) Usage Scenario Transcribe while speaking Upload the whole file after recording Speaker Diarization Not supported Up to 8 speakers Word-level Timestamps Not supported Supported Audio Length 10 minutes per session 1 hour (30 mins with diarization) Smart Mode SMART available smart is mutually exclusive with diarization Interim Subtitles Has interimInputTranscription Not applicable The official documentation on the Live page's limitations section is very blunt: Speaker diarization is not supported in live streaming sessions. For speaker diarization, use the non-streaming Audio transcription endpoint. So, "seeing who