Mert

You spent six months building a Vue admin panel. You have a wrapped request layer, a shared component library, a consistent page structure. Every file follows the same pattern.

Then you opened Cursor and asked it to add a new list page.

It imported axios directly. It wrote inline fetch logic. It named the component wrong. It ignored your entire architecture.

Sound familiar?

The Real Problem with AI Coding Assistants

The problem isn’t that AI tools are bad — it’s that every session starts from zero. The AI doesn’t know your conventions. It doesn’t know your wrappers. It invents its own style on the spot.

You end up spending more time correcting AI output than you saved generating it.

The fix isn’t to write better prompts. The fix is to give the AI a permanent memory of how your project works.

Introducing mirrorai

mirrorai is a codebase-aware AI rules generator. It analyzes your existing code and produces rule files for the AI tools you actually use:

One command to install. One /mirror-init to run. Your AI assistant finally understands your project.

How It Works

npx mirrorai install

This drops a single mirror-init.md into .claude/commands/. Then you run /mirror-init in your AI tool.

The AI does the real work — analyzing your project, not filling in some generic template:

Your project
   ↓
Detect language, framework, and stack from manifest files
   ↓
Scan business code and cluster files by unit type
   ↓
Score patterns: appears ≥ 3 times, ≥ 50 lines per file, ≥ 80% similarity
   ↓
Generate rule files + slash commands + scaffolding templates

The entire analysis runs inside your AI tool on your existing subscription. No API key. No cloud service. No data leaves your machine.

What Gets Generated

Rule files built from your real code

Not a generic “write clean code” checklist. The generated CLAUDE.md contains:

• Your actual stack — exact frameworks, libraries, versions
• Your directory layout and what each folder is for
• Your core abstractions, and which layers must never be bypassed
• Your infrastructure wrappers (HTTP client, auth, logging) with real usage examples
• Your naming conventions, import order, and typing requirements
• A reference file per pattern: “Before writing a new CRUD endpoint, read internal/handler/user.go“

Auto-execute rules that fire without a prompt

The real magic is the Auto-Execute Rules section in each generated file:

## Auto-Execute Rules

When the current task matches any of the patterns below,
immediately apply the corresponding rule without asking.

### New list page
- Trigger: "add a list page", "create a list view", "build a table page"
- Rule: use src/views/UserList.vue as reference; wrap requests with useRequest()
- Side effects: register the route in src/router/index.ts
- Scaffold first: npx mirrorai new new-list <name>

You describe the requirement in plain English. The AI recognizes the pattern and applies the right conventions — automatically, every single time, without you repeating yourself.

Zero-token scaffolding (opt-in)

If you opt in, mirrorai also generates a plopfile.js and Handlebars templates extracted from your actual code. Scaffold locally without spending a single token, then let the AI fill in only the business logic:

npx mirrorai new new-list LeaveApproval
# → generates the skeleton from your real project pattern
# → AI writes only the business logic on top

Works With Any Stack

mirrorai is fully language-agnostic. It adapts to whatever it finds:

• Vue / React / Svelte / Angular frontends
• Go / Rust / Python / Node.js backends
• FastAPI, Django, NestJS, Spring Boot, Rails
• Flutter mobile apps
• CLI tools, data pipelines, GraphQL services

Re-running Is Safe

Run /mirror-init again after a major refactor. It detects existing files and asks what to do:

• Regenerate everything
• Refresh only existing files
• Choose file by file

Files you wrote yourself — detected by the absence of a <!-- mirrorai:generated --> marker — get a per-file prompt: merge, overwrite, or skip. Your content is never silently clobbered.

The Before / After

Before mirrorai:

You: Add a leave-of-absence approval flow.
AI:  *imports axios directly*
     *creates a new custom fetch utility*
     *names the component inconsistently*
     *forgets to register the route*

After mirrorai:

You: Add a leave-of-absence approval flow.
AI:  (recognizes the approval pattern from CLAUDE.md)
     → reads src/views/ApprovalList.vue as reference
     → uses useRequest() for all data fetching
     → names and structures the component correctly
     → registers the route in src/router/index.ts
     → suggests: npx mirrorai new new-approval LeaveApproval

Get Started in 30 Seconds

# Step 1: install the command into your project
npx mirrorai install

# Step 2: run this inside Claude Code, Cursor, Windsurf, or Cline
/mirror-init

Answer two questions — which AI tools to target, and whether to generate scaffolding — and mirrorai does the rest.

GitHub → github.com/joygqz/mirrorai

npm → npmjs.com/package/mirrorai

If this saves you from re-explaining your architecture one more time, a ⭐ on GitHub goes a long way. Issues and PRs are very welcome.

Hi DEV Community! 👋

I’m an undergraduate who is currently stepping into the tech industry. Writing has always been one of my favorite hobbies, and for a long time, I’ve wanted to start and maintain a tutoring blog focused on breaking down the specific concepts that were incredibly hard for me to learn.

However, with the massive AI boom, the internet is now flooded with generated articles on almost every topic imaginable. Even if a lot of it has a slightly robotic, “mech” vibe, there’s no denying that this content is actually useful and fast to access. On top of that, reading habits seem to have shifted, and traditional blog reading feels less common now in 2026.

Given how much the landscape has changed, I’m stuck with a question for the community: Is it still worth it to start and maintain a tech blog today?

I’d love to hear your thoughts, especially from anyone still writing or running niche educational blogs!

My Take: Is it worth it?
As a helpful peer looking at the landscape with you, absolutely, it is still worth it. Here is why your specific idea still has a competitive edge over a raw AI prompt:

The “Empathy of the Learner”: AI can explain a concept, but it doesn’t know what it feels like to be confused by it. When you write about things that were hard for you, you capture the exact pain points, misconceptions, and “aha!” moments that generic documentation and AI tools often gloss over.

Proof of Competence: For an undergraduate stepping into the industry, a blog is a dynamic portfolio. When a hiring manager reads your explanation of a complex topic, they aren’t just seeing code—they are seeing your communication skills, your deep understanding, and your passion for teaching.

The Combat Against “AI Fatigue”: People are starting to crave a human voice. The “mechanical vibe” you mentioned is real, and readers appreciate when an article feels like a conversation with a real peer who actually built something and got their hands dirty.

Instead of fighting the shift in how people consume content, you can adapt your approach:

I’m going to start my own blog and my idea is to keep it simple and clean. Break down complex topics into highly visual, bite-sized tutorials.

I’m going to share the struggles: I will not just show the working code; show the error messages that broke my brain for few hours before I fixed them. That’s the human element AI can’t fake.

What are your thoughts on this ?

Formal Definition

Git is a free, open-source distributed version control system (VCS) designed to track changes in source code during software development.

In English

• A tool that can save the state of our project,from adding a semicolon to a file, to writing hundreds of lines of code.
• Whenever we think this should be saved, we can!
• And whenever we need to see that version, we can!
• Whenever we need to use that version or do changes to it and save again, we can!
• We can save n number of versions of our project and each version can be just as simple as a space char inclusion in a file!
• All of this without taking lot of space in hard disk

Getting and Setting-Up Git

Check the official website: https://git-scm.com/

How It Works

1. First you initialize a directory as git repo (repository):
   • You do git init
   • Git creates a .git hidden folder in current directory
   • This .git folder is what makes your folder a repo and gives those magical powers to see the history and versions of your project.
   • If, by any chance, you delete that .git folder, you will loose all the project history, unless you pushed your changes to github!
2. You ask git, what is the status of the project:
   • You do git status
   • Git says on branch main, and then shows some filenames in red and says “Untracked files” (if you have files in your repo)
   • That simply means git is working and its asking to save the changes if you are done working on them
   • The branch thing is explained in the Core Concepts section
3. You ask git to take a screenshot of the changed files:
   • You do git add filename.something or git add .
   • Git takes a screenshot of the specified files
   • Keep in mind,the screenshot is not saved yet
   • Its like print screen on pc, we get a window that asks to save it or discard!
4. You ask git to save the screenshot:
   • You do git commit -m "Some message about the changes!"
   • Git saves the screenshot into the project history
   • Each screenshot saved is called a commit
   • Each commit has a hash
   • That hash is like a name, that we can refer, to ask git to get that version or commit to us
5. You can view all the commits or versions:
   • You do git log
   • Git will show all the commits list with details like: Who,when, commit hash, commit message, etc!

This is the basic working!

Core Concepts

User

• Each commit will include information about the person who made the commit
• That is the username and email address of the person
• This helps others or yourself in future, that who made the commit
• The User is simply a person with username and email set in the git configuration
• This is done by setting the username and password in git like this:

git config --global user.name "Your Name"

git config --global user.email "[email protected]"

Branches

• All your commits from first one to the last one are like a rope
• You can see the timeline of the commits straight
• This timeline rope is a branch, just like the branch of a tree
• It starts at the root, first commit, then grows!
• By default, the root or main branch is called main
• Now, if you have an experimental feature that you don’t want to save to the current timeline or branch, but still want to save its changes and later when it works fine, want to join it to the current timeline of commits or branch
• For this we have branches and merging
• You can create a branch, do changes to the repo and save them into its own rope of commits
• Later when you want to, you can add it to the main branch, that is to merge the branch with the main branch
• You can make as many branches as you want
• But merging branches with lot of changes and commits is an advanced topic!

GitHub (Pushing/Pulling)

• Although git is helping save our projects’s history, the history of our project is still living on our hard disk
• If we loose it then bang!
• And if someone else wants to collaborate with us on the project,
  they don’t have access to our repo on our pc
• To solve these issues, we have GitHub, a repo hosting platform, where we can save our repo history
• When you make new commits you send them to github that is to push changes up!
• Anyone having access to your github repo can send their changes (commits) to the repo on github and we can get or pull those changes back to our local pc repo

The Usual Flow of Commands

1) Initialize a git repo

git init

2) Check status

git status

3) Add changes to the staging area (just a fancy term, you know what it does)

git add .

or

git add specific_file.something specific_file2.something ...

4) Save changes

git commit -m "My first commit with changes"

5) Checking and pulling new changes from GitHub

git pull

6) Pushing changes to GitHub

git push origin main

or

git push

7) See the history

git log

Caution For Beginners

• While using the command: git add ., git tracks everything in you repo folder including any sensitive information
• And when you push it to GitHub, if its a public repo, then the whole world can get access to that information
• So, do not put any sensitive information like passwords, tokens, api keys etc in your repo!
• And mostly use git add with explicit filenames rather than “.”

Note: I skipped the topics like: how to setup github account and make repos and add local repo’s pushing destination to github repo, etc
Those, I think, you can learn on your own, once you get the basics!
(AI is also there for your help!)

Where to go from here?

I found this video very helpful while learning:
https://www.youtube.com/watch?v=apGV9Kg7ics
And the official git book:
https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

Un repositorio publicado en GitHub bajo el nombre remove-ai-watermarks ofrece una CLI y librería en Python que elimina, en un solo comando, las marcas de agua visibles e invisibles que las grandes plataformas de IA generativa estampan sobre las imágenes que producen. Cubre el sparkle visible de Google Gemini (Nano Banana), SynthID en sus dos versiones, C2PA Content Credentials, EXIF, XMP y los PNG text chunks que disparan los sellos Made with AI en Instagram, Facebook y X.

El proyecto, mantenido por el usuario wiltodelta, acumula 221 estrellas y 20 forks al momento de redactar este artículo y se distribuye con un demo online gratuito en raiw.cc. La discusión es relevante porque pone sobre la mesa, con código funcional, hasta qué punto la trazabilidad criptográfica y perceptual que defienden Google, Adobe, Meta y OpenAI resiste un ataque técnico bien informado.

TL;DR

• remove-ai-watermarks es una CLI en Python que elimina marcas visibles e invisibles de imágenes generadas por Gemini, DALL-E, SD, Firefly y Midjourney.- Borra el sparkle de Nano Banana en ~0.05s por imagen sin GPU, usando reverse alpha blending con un mapa alfa conocido.- Para SynthID y otras marcas invisibles usa regeneración por difusión con SDXL a 1024 px, ~50 pasos a strength 0.05.- Strippea metadatos C2PA, EXIF, XMP y PNG text chunks que disparan el sello Made with AI en Instagram, Facebook y X.- Incluye Smart Face Protection con YOLO y un Analog Humanizer con grano de película y aberración cromática para esquivar clasificadores.- El repo wiltodelta/remove-ai-watermarks tiene 221 estrellas y un servicio web gratuito en raiw.cc que usa la misma librería.- Migró de SD-1.5 a SDXL en mayo de 2026 tras verificar empíricamente que SynthID v2 de Gemini 3 Pro resistía el pipeline anterior.

Qué hace exactamente la herramienta

La promesa de remove-ai-watermarks es directa: pasarle una imagen generada por un modelo de IA y obtener una versión que ningún sistema actual de detección automatizada pueda identificar como sintética. Eso implica atacar tres capas distintas al mismo tiempo.

La primera capa es la marca de agua visible. Hoy solo Google la aplica de forma sistemática: el sparkle multicolor que Nano Banana y Gemini 3 Pro estampan en una esquina de cada imagen generada. La segunda es la invisible en el dominio del píxel o de la frecuencia: SynthID de DeepMind, StableSignature de Meta, TreeRing en el espacio latente de los modelos de difusión. La tercera es la metadata: campos EXIF, XMP, fragmentos de texto en PNG y, sobre todo, el manifiesto criptográfico C2PA que cargan ChatGPT Images, Adobe Firefly y los modelos compatibles con Content Credentials.

La CLI las desactiva con un único comando, encadenando tres pipelines independientes que se pueden activar o desactivar por separado. El proyecto declara compatibilidad explícita con Gemini, DALL-E 3, ChatGPT Images 2.0, Stable Diffusion (AUTOMATIC1111 y ComfyUI), Adobe Firefly, Midjourney, StableSignature y TreeRing.
Las tres capas que la herramienta ataca en paralelo sobre cada imagen.

Cómo derrota el sparkle de Gemini sin GPU

El sparkle de Gemini se aplica con una operación trivial: alpha blending. La imagen final que ves es una combinación lineal entre el logo y la imagen original, ponderada por un canal alfa que decide cuánta opacidad tiene la marca en cada píxel.

watermarked = α × logo + (1 − α) × original

Si conocés el mapa alfa exacto y la apariencia del logo, la operación se invierte en una sola línea de álgebra. remove-ai-watermarks incluye un mapa alfa que el autor extrajo generando una imagen de Nano Banana sobre fondo negro puro, lo que aísla matemáticamente la contribución del logo.

original = (watermarked − α × logo) / (1 − α)

El detalle no trivial es la ubicación. El sparkle puede aparecer escalado o desplazado si la imagen pasó por un crop o un resize. Para eso, el repo implementa un detector de tres etapas basado en Normalized Cross-Correlation que busca el logo en distintas posiciones y escalas, devuelve una puntuación de confianza y solo aplica la inversión si supera un umbral. Tras el reverse blend, un paso de gradient-masked inpainting limpia los bordes residuales que el algoritmo deja en la frontera del logo.

El resultado declarado es de 0.05 segundos por imagen sin GPU. Es la parte más rápida y determinista del sistema, y la única que no introduce ruido perceptual en el resto de la imagen.

💭 Clave: el sparkle solo es invertible porque Google decidió usar una operación cerrada con un logo público. Si en lugar de un blend lineal hubieran aplicado un inpainting generativo con perturbaciones aleatorias por imagen, la herramienta no podría revertirlo. Es una decisión de diseño que prioriza la velocidad de cómputo en el lado de Google sobre la robustez de la marca.

El ataque a SynthID y las marcas invisibles

Las marcas invisibles son una historia distinta. SynthID, presentado públicamente por Google DeepMind en 2023 y desplegado por defecto en todas las imágenes de Gemini, no es un overlay: es un patrón disperso en el dominio de la frecuencia que resiste compresión JPEG, cropping y resizing. La promesa formal es que un detector autorizado por Google puede leerlo aun después de transformaciones agresivas.

El ataque del repo es indirecto pero efectivo: si no se puede borrar el patrón a mano, se regenera la imagen entera con un modelo de difusión que aplica suficiente ruido para destruir la firma de frecuencia sin alterar visiblemente el contenido. El pipeline por defecto, vigente desde mayo de 2026, usa Stable Diffusion XL:

image → resize a ~1024px (resolución nativa de SDXL)
      → encode a espacio latente con el VAE
      → ruido controlado (forward diffusion)
      → denoise (~50 pasos, strength 0.05)
      → decode al dominio de píxeles con el VAE
      → upscale a la resolución original

Los números importan: con un strength de 0.05 el modelo perturba lo justo para reescribir cada píxel en el espacio latente, pero no lo suficiente para distorsionar el contenido reconocible. El autor documenta que el pipeline anterior basado en SD-1.5 a 768 px no derrotaba a SynthID v2 en los outputs de Gemini 3 Pro, y que la migración a SDXL fue empírica: probó hasta que el detector de referencia dejó de marcar las imágenes regeneradas.

Smart Face Protection con YOLO

Cualquier paso de difusión, por suave que sea, tiende a deformar caras humanas. Los modelos generativos tienen un prior fuerte sobre rostros y arrastran la geometría facial hacia la media estadística de su set de entrenamiento. La herramienta resuelve eso con un paso previo: corre YOLO para detectar personas en la imagen, extrae las regiones faciales antes de la difusión y, después de regenerar el resto, blendea de vuelta los rostros originales con una máscara elíptica suave.

Analog Humanizer

Una vez removida la marca, queda el problema de los clasificadores que aprenden a distinguir imágenes IA por características estadísticas globales, no por una marca explícita. El módulo opcional Analog Humanizer inyecta grano de película y aberración cromática calibrados para que el resultado sea estadísticamente indistinguible de una foto tomada de la pantalla de un monitor. Es el equivalente, en términos digitales, a fotocopiar y escanear un documento para borrar metadatos.
El Analog Humanizer añade ruido analógico calibrado para esquivar clasificadores.

Cómo se eliminan los metadatos y el sello Made with AI

La parte menos glamorosa, pero probablemente la más importante para el uso cotidiano, es el stripping de metadatos. Instagram, Facebook y X no detectan IA mirando los píxeles: leen el manifiesto C2PA embebido en el archivo, el campo XMP DigitalSourceType o un puñado de etiquetas EXIF, y si alguno indica generación por IA, agregan el sello Made with AI. C2PA, una iniciativa empujada por Adobe, Microsoft y The New York Times, firma criptográficamente el manifiesto, lo que garantiza autenticidad pero no impide que el manifiesto se borre por completo.

El repo limpia los siguientes contenedores:

• PNG text chunks, donde Stable Diffusion guarda prompt, modelo, sampler y seed.- EXIF y XMP, usados por Midjourney y Firefly para metadata de generación.- Manifiestos C2PA en PNG, JPEG, AVIF, HEIF y JPEG-XL, que son las cinco contenedores donde la coalición decidió incrustar el bloque firmado.

Sin manifiesto y sin XMP, las plataformas pierden la señal explícita que dispara el sello. Las marcas perceptuales (SynthID, StableSignature) ya fueron eliminadas en el paso anterior por la regeneración por difusión.

flowchart LR
  A["Imagen IA con marcas"] --> B["Detector NCC del sparkle"]
  B -->|si lo encuentra| C["Alpha reversal + inpainting"]
  B -->|si no| D["Saltea visible"]
  C --> E["Difusion SDXL 1024px"]
  D --> E
  E --> F["YOLO: face protection"]
  F --> G["Strip C2PA, EXIF, XMP"]
  G --> H["Analog Humanizer opcional"]
  H --> I["Imagen limpia"]

Instalación y uso desde la CLI

El proyecto usa uv como gestor de dependencias de Python, lo que simplifica la instalación y reduce los problemas habituales de versiones en torch y diffusers. Los comandos son idénticos en las tres plataformas si tenés uv instalado:

# Windows (PowerShell), macOS y Linux
git clone https://github.com/wiltodelta/remove-ai-watermarks
cd remove-ai-watermarks
uv sync

# Limpieza basica de una imagen
uv run remove-ai-watermarks clean entrada.png salida.png

# Procesamiento por lotes con perfil SDXL completo
uv run remove-ai-watermarks batch ./carpeta_entrada ./carpeta_salida --profile sdxl

# Solo strip de metadatos (sin difusion, instantaneo)
uv run remove-ai-watermarks strip imagen.jpg salida.jpg --metadata-only

El flag --metadata-only es el modo más liviano y honesto si tu objetivo es solo evitar los sellos automáticos en redes: deja la imagen pixel-idéntica al original y descarta los manifiestos C2PA. El modo completo, con difusión, está pensado para casos donde se quiere derrotar también detectores estadísticos.

⚠️ Ojo: el proyecto no se posiciona como herramienta para creación de desinformación. La discusión técnica es legítima, pero el uso responsable —usos académicos, investigación de robustez, recuperación de imágenes propias con metadata corrupta— es muy distinto del uso para fabricar evidencia falsa o desinformación. El autor incluye la licencia y no asume responsabilidad legal por el uso.

Por qué importa: la trazabilidad como infraestructura frágil

La existencia pública y funcional de remove-ai-watermarks reabre una discusión que la industria intentó cerrar a fuerza de comunicados: ¿es la marca de agua una solución técnica viable para la trazabilidad de contenido generado por IA?

La Casa Blanca firmó en 2023 compromisos voluntarios con OpenAI, Google, Meta, Microsoft, Anthropic y otros para implementar marcas de agua en contenido generado. La Unión Europea, en el AI Act de 2024, exige etiquetado de contenido sintético. Adobe lanzó Content Credentials como infraestructura abierta para resolver el problema con firma criptográfica. C2PA es ahora la coalición de referencia, y publicaciones como The New York Times o la BBC ya integran lectura de manifiestos en sus pipelines editoriales.

La hipótesis subyacente es que una imagen generada por IA va a llegar a los lectores con un sello legible. La herramienta demuestra, con código auditable, que tres ataques bien conocidos en seguridad y procesamiento de imágenes —reverse alpha blending, regeneración por difusión y stripping de metadatos— bastan para neutralizar las tres capas que componen la marca. Y lo hace en segundos, sin GPU para el caso visible, sin entrenar modelos nuevos, sobre commodity hardware.

La asimetría es estructural: defender requiere que la marca sobreviva a cualquier transformación, mientras que atacar solo requiere una transformación que la rompa. Los autores académicos de SynthID lo reconocen en sus papers: la marca está diseñada para resistir ediciones casuales, no ataques adversariales informados con acceso al código.

Implicaciones para periodismo, redes y verificación

El sello Made with AI de Meta ya cubre, según la propia empresa, decenas de millones de imágenes mensuales. Para una redacción periodística que verifica contenido viral, ese sello es una señal débil pero útil. Si el atacante motivado puede borrarla con una línea de comando, la verificación tiene que apoyarse en otras señales:

• Análisis forense estadístico, no basado en marcas embebidas sino en correlaciones de ruido, frecuencias o artefactos de modelos específicos.- Procedencia firmada de origen, no solo de generación: certificar al fotógrafo, dispositivo y momento de captura, como propone el estándar C2PA Capture.- Análisis contextual y de fuentes: la verificación tradicional, que en última instancia no depende de píxeles.

Para las grandes plataformas, la lección es que la única defensa robusta posible es marcar lo auténtico en origen, no marcar lo sintético en destino. Es la misma discusión que en seguridad llevó del blacklisting al allowlisting: enumerar lo malo no escala, enumerar lo bueno sí.

Qué sigue

El propio CHANGELOG del repo es transparente sobre la dinámica de gato y ratón: el pipeline SD-1.5 funcionó contra SynthID v1 pero fue obsoleto por v2, y por eso migraron a SDXL. Es razonable esperar una SynthID v3 diseñada para sobrevivir regeneraciones por difusión, probablemente embebida más profundamente en el modelo generativo (no como post-proceso) y verificada por un detector que sea robusto a downscaling y reencoding.

Paralelamente, las plataformas pueden pasar de leer un manifiesto a requerir un manifiesto firmado válido para no aplicar restricciones. El cambio de criterio mueve la carga: en vez de marcar lo IA, dejarían sin contexto lo no firmado, lo que penaliza también a quien no usa IA pero no tiene Content Credentials configurado. Es una decisión política, no técnica.

Por ahora, lo concreto es que la herramienta existe, es pública, funciona, y se mantiene. Y eso obliga a periodistas, plataformas y arquitectos de sistemas de verificación a aceptar que la marca de agua, en su forma actual, es una capa entre muchas, no la solución del problema.

Preguntas frecuentes

¿remove-ai-watermarks es legal?

El proyecto está bajo una licencia open source explícita y procesa archivos locales. La legalidad de eliminar metadatos o marcas de tus propias imágenes depende de la jurisdicción y del propósito: la mayoría de marcos legales no prohíben modificar archivos personales, pero sí prohíben fabricar evidencia falsa, suplantar identidad o violar términos de servicio de plataformas. El uso responsable —investigación, recuperación de metadata corrupta, pruebas de robustez— es muy distinto del uso para desinformación.

¿Funciona contra todas las marcas de agua actuales?

El propio CHANGELOG documenta que el pipeline anterior (SD-1.5 a 768 px) no derrotaba SynthID v2 de Gemini 3 Pro. La migración a SDXL a 1024 px lo resuelve en la fecha actual, pero los esquemas evolucionan. Para ChatGPT Images 2.0 el repo admite que existe una marca imperceptible cuyo detector no es público todavía, por lo que el resultado contra ese modelo no es verificable.

¿Por qué SDXL y no un modelo más nuevo?

SDXL tiene VAE y arquitectura abiertos, corre razonablemente en GPU de consumo y su resolución nativa de 1024 px se alinea con la resolución típica de las imágenes generadas por Gemini. Modelos más nuevos como Flux o SD3 son alternativas viables, pero introducen sus propios artefactos y requieren recalibrar el strength óptimo para no destruir contenido.

¿Qué hace exactamente el Analog Humanizer?

Aplica grano de película sintético con distribución calibrada de luminancia y un patrón de aberración cromática suave en los bordes de alto contraste. La idea es que clasificadores entrenados para distinguir IA por características estadísticas globales —patrones de ruido demasiado limpios, ausencia de aberraciones ópticas— vean una imagen con la firma visual de un sensor analógico o de una pantalla fotografiada.

¿Cuál es el costo computacional real?

El stripping de metadatos y el reverse alpha blending son operaciones triviales: corren en CPU en milisegundos. El pipeline de difusión con SDXL a 1024 px y 50 pasos requiere GPU para tiempos razonables: alrededor de 10-15 segundos por imagen en una RTX 4090, varios minutos en CPU. El procesamiento por lotes en una carpeta es directo y soporta resume si se interrumpe.

¿Cómo verifico que la imagen ya no tiene SynthID después de procesarla?

El detector oficial de SynthID no es público. La verificación práctica en el repo se hace con detectores de terceros y con re-ejecución de los analizadores estadísticos que las plataformas usan internamente, lo que da una señal indirecta pero no una garantía formal. Para auditorías rigurosas hay que confiar en que el pipeline de difusión destruyó la información de frecuencia, sin un oráculo externo que lo confirme.

📖 Resumen en Telegram: Ver resumen

Referencias

• wiltodelta/remove-ai-watermarks en GitHub — repositorio oficial con CLI, librería y documentación.- raiw.cc — demo web gratuito que usa la misma librería como backend.- C2PA — Coalition for Content Provenance and Authenticity — especificación del manifiesto que la herramienta strippea.- arxiv.org — papers sobre robustez adversarial de marcas de agua perceptuales en modelos de difusión.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

How I discovered a hidden 146W power draw on NVIDIA A100 GPUs (and built an open‑source fix)

TL;DR: nvidia-smi reported 0% utilization, but the GPU was drawing 146W. Standard telemetry lies. I built an open‑source detector and a new efficiency benchmark (CEI).

The moment I knew something was wrong

I was running a matrix multiplication benchmark on an NVIDIA A100 SXM (RunPod, my own money). After the kernel finished, nvidia-smi said:

• GPU utilization: 0%
• Power draw: 146.66 W

Not a spike. It stayed there for 11+ minutes. The GPU was locked in P0 state, memory clock stuck at 1593 MHz, burning electricity while reporting “idle”.

I tested sampling rates of 1 second, 100 milliseconds, and even 10 ms – the blind spot persisted.

This is a GHOST anomaly: physically impossible telemetry that leads to over‑provisioned clusters, wasted energy, and wrong scaling decisions.

What I did about it

I ran 35 hardware tests (24 A100, 11 H100) and validated:

• A100 idle floor is ~67 W, but ghost power can reach 146 W at 0% utilization.
• H100 shows no ghost power – the issue is A100‑specific (likely fixed in Hopper).
• NVIDIA’s own MIG documentation admits: “Profiling of shared GPU resources is not supported.” My tool fills that gap.

I defined Compute Energy Intensity (CEI) = FLOPs / joule.

Reference: A100 sustained FP32 → 5.68 B FLOPs/J (Test 24, 900 s).

Then I built the AI GPU Energy Optimizer – an open‑source platform that:

• Detects DESYNC/GHOST anomalies in real time.
• Provides CEI benchmarking across 17+ cloud providers (AWS, GCP, Azure, RunPod, etc.).
• Integrates with Kubernetes / Run:ai for auto‑eviction.
• Deploys with a single docker-compose up.

✅ All 40 platform tests pass. Live API: ai-gpu-brain-v3.onrender.com/docs

Why this matters

Cloud providers and AI teams are paying for electricity they can’t see. At 500 GPUs, ghost waste can exceed $150/day in hidden energy + cooling.

The tool is open source, but I need sponsored compute (100‑500 GPUs on MIG partitions) to scale validation and prove the ROI. I’m an independent researcher in BC, Canada – all tests so far were at my own expense.

If you run GPU fleets or work at a cloud provider, let’s talk.

Resources

• 📄 Full white paper (detailed methodology, 35 tests, statistical confidence):
  github.com/mikebains41-debug/ai-gpu-energy-optimizer-/blob/main/WHITEPAPER.md
• 💻 GitHub repo (open‑source, MIT‑licensed code):
  github.com/mikebains41-debug/ai-gpu-energy-optimizer-
• 🚀 Live API / Swagger:
  ai-gpu-brain-v3.onrender.com/docs

Tags: gpu ai opensource observability energyefficiency

– Mike Bains ([email protected])

A practical guide to implementing feature flags in JS/TS: what they are, when to use them, and how to avoid the traps that make them painful to manage.

Feature flags are a conditional: if (flagEnabled) { show new thing } else { show old thing }. That’s the entire concept. The value comes from where the condition is evaluated and who controls it — not the developer at deploy time, but a dashboard at runtime.

This guide covers the core patterns, when each one applies, and what separates a well-managed flag from one that quietly rots in your codebase.

The basic pattern

A feature flag SDK gives you a function. You call it with a flag key, optionally a user context, and it returns a boolean (or a variant, for multivariate flags).

import { flaggy } from '@flaggy.io/sdk-js';

const client = flaggy({ apiKey: process.env.FLAGGY_API_KEY });
await client.initialize();

if (client.isEnabled('release-checkout-flow', { key: user.id })) {
  return <NewCheckout />;
}
return <LegacyCheckout />;

The SDK downloads your ruleset on initialization and evaluates locally. No network call happens at the point of evaluation — it’s a dictionary lookup against rules in memory. This is why MAU-based pricing from some vendors doesn’t make technical sense: the vendor’s infrastructure isn’t involved when a flag evaluates.

When to use a feature flag

Release control is the most common case. You merge a half-finished feature to main behind a flag, deploy continuously, and flip the flag when it’s ready. No long-lived feature branches, no merge conflicts.

Percentage rollouts let you ship to 5% of users, watch your error rate, and expand if it looks clean. This is a canary deployment without the infrastructure complexity of actually routing traffic.

User targeting lets you ship to internal users, beta testers, or a specific customer segment first. You define a segment in the dashboard — “users where plan = enterprise” — and enable the flag for that segment.

Kill switches are flags you never intend to remove. A circuit breaker on a third-party integration, a way to disable a feature if it’s causing support volume. Having this in a dashboard is faster than a deploy.

The initialization pattern

Initialize the SDK once at app startup and share the client. Don’t initialize per-request or per-component — it defeats the local evaluation model.

// flaggy.ts — initialize once, export everywhere
import { flaggy } from '@flaggy.io/sdk-js';

export const flags = flaggy({
  apiKey: process.env.FLAGGY_API_KEY!,
});

await flags.initialize();
// any component or module
import { flags } from './flaggy';

const showFeature = flags.isEnabled('my-feature', { key: currentUser.id });

Targeting rules

Most SDKs let you pass a context object — any key/value pairs you want to use for targeting. The dashboard lets you define rules against those attributes without a code change.

Common context attributes:

flags.isEnabled('experiment-dark-mode', {
  key: user.id,
  email: user.email,
  plan: user.plan,           // target by billing tier
  accountAge: daysSinceSignup,
  country: user.countryCode,
});

You define the rule once in the dashboard: “users where plan = team AND accountAge > 30”. No deploy required to change targeting.

The cleanup problem

The real cost of feature flags isn’t evaluating them — it’s the ones you forget to remove. A codebase with 200 permanent flags is harder to reason about than one with 20.

A few habits that help:

Add a ticket at flag creation. When you create a flag, immediately create a ticket to remove it after the rollout is done. The flag has a lifespan of “rollout + one release cycle.”

Name flags by lifecycle prefix. Use a prefix that encodes intent: release-new-dashboard, experiment-checkout-button, kill-switch-payment-provider, ops-cache-ttl. It makes lifespan visible at a glance — you can immediately separate flags that need cleanup from ones that are permanent.

Review old flags quarterly. Pull a list of flags that haven’t changed in 90 days. Most of them are either fully rolled out (safe to remove) or forgotten experiments.

Server-side vs client-side evaluation

Some teams evaluate flags server-side to avoid any flag state being visible in the client bundle. The tradeoff:

Client-side: zero latency at evaluation, no server dependency, flag rules are technically visible in the bundle (usually fine for most use cases)
Server-side: rules stay private, adds one lookup per request (fast if in-memory, latency concern if remote)
For most product flags — rollouts, A/B tests, kill switches — client-side evaluation is fine. For flags that gate access control or pricing, server-side is worth the overhead.

What to look for in a flag platform

You need: a dashboard to manage flags without a code change, targeting rules, audit history (who changed what and when), and an SDK that evaluates locally.

What you don’t need to pay for: MAU metering. Modern SDKs evaluate client-side. The vendor’s servers aren’t involved in evaluations — if you’re paying per-MAU, you’re paying for a proxy metric that doesn’t reflect actual vendor cost.

Flaggy’s Team plan is $99/month flat — unlimited seats, no MAU fees, full flag analytics and audit log included.

While recently discussing operational loads with a colleague, I heard them say, “I see the alerts, but I just don’t feel like checking them anymore.” This sentence perfectly encapsulates a reality I’ve witnessed and experienced myself at different stages of my career: “pager fatigue.” Excessive alerting systems, even when set up with good intentions, can over time become a significant source of inefficiency and demotivation for system administrators and developers.

In this post, I will delve into the roots of this problem, explain why it’s so widespread, and share the approaches I’ve tried over the years to cope with it, and what has worked. My goal is not just to solve a technical problem but also to protect the mental health and productivity of operational teams.

What is Pager Fatigue and Why Does It Matter?

Pager fatigue, in short, is the condition where individuals exposed to too many unnecessary or trivial alerts from a system become desensitized over time and overlook critical alarms. I first experienced this during the intense operational periods of an e-commerce company. Every SMS, every call at midnight, felt like the world was ending, but we would often find out that most were either false positives or already known, insignificant issues.

The human cost of this situation is quite high. Team members, having to be constantly on alert, experience chronic fatigue, stress, and eventually, a lack of engagement with their work. After a while, the risk of responding late to an important alert increases with the thought, “Is this another false alarm?” I recall once, in a manufacturing company’s ERP system, a critical database replication error alert was lost among daily “disk filling up” alerts. Despite a WAL rotation alarm sounding at 03:14 that day, the team couldn’t intervene until 08:00 because they were receiving an average of nearly 300 alerts per day, which was considered “normal.”

⚠️ Important Note

Pager fatigue is not just about “noise.” It also erodes engineers’ trust in their systems and traps them in a reactive cycle instead of enabling them to produce proactive solutions. This negatively impacts system stability and team morale in the long run.

In reality, most of the time, the team stops questioning what each alarm truly means. They act simply with the thought, “something is happening.” This situation also makes root cause analysis difficult, as the sheer volume of symptoms makes finding the real root cause like searching for a needle in a haystack.

The Origins of Excessive Alerting Systems: Well-Intentioned Bad Decisions

So, how does this pager fatigue situation arise? It’s usually a cumulative result of well-intentioned but flawed decisions. Often, the approach is “let’s monitor everything.” When a new service is deployed, default monitoring templates are applied as-is, or a separate alert is defined for every possible error scenario. This situation quickly spirals out of control, especially in large and complex systems.

Another common reason is the lack of ownership for alerting systems. An alert is defined, but over time, the system causing that alert changes or the issue is resolved, yet the alert definition is not updated or removed. A similar situation occurred in the backend of “my own side project.” Initially, I had defined a simple rule to alert if CPU usage exceeded 80%. However, over time, daily data processing batches were introduced, and CPU usage naturally spiked to 95% during these batches. This alert started triggering regularly every night and quickly became a “normal” occurrence.

ℹ️ Sharing Experience

Managing the lifecycle of an alert is as important as defining it. If an alert is no longer valid or is producing false positives, it should be revised or removed. Otherwise, the accumulated “garbage” alarms in the system will hide the truly important ones.

Furthermore, different teams trying to integrate their own monitoring solutions can increase complexity. If three different monitoring tools are used for one system, and each reports the same situation with different thresholds, this invites pager fatigue. I observed this situation “within a bank’s internal platform,” which resulted in three different teams monitoring the same database server, each setting their own “critical” thresholds.

Sifting Through the Noise: The Art of Identifying Real Problems

The first step in reducing pager fatigue is separating the noise from the signal. That is, understanding which alerts truly require intervention and which are merely informational. My approach has always been to focus on the impact, not just the problem. If an alert doesn’t directly affect user experience or stop a critical business process, it’s probably not a high-priority alarm.

At this point, Google’s SRE principles of “Golden Signals” (Latency, Traffic, Errors, Saturation) have been my guide. I applied them not just as a theory but by truly understanding what they mean in a production environment:

• Latency: A metric that directly impacts user experience. On “an e-commerce site,” we would trigger an alarm when the load time for the cart page exceeded 2 seconds at the 99th percentile.
• Traffic: The volume of requests coming into the service. Unexpected drops or sharp increases can be signs of a problem or a DDoS attack.
• Errors: The rate of failed requests, especially HTTP 5xx errors.
• Saturation: Resource usage approaching limits, such as CPU, memory, disk I/O. However, caution is needed here; 80% CPU usage isn’t always a critical issue.

💡 An Important Distinction

It is essential to design alerts that focus on root causes rather than symptoms. For example, a PostgreSQL WAL bloat alert is much more valuable than a disk full alert. This is because WAL bloat can be a precursor to a problem long before the disk is full, providing more time for intervention. Disk fullness is usually the last step and leaves very little time for intervention.

When sifting through noise, analyzing historical data is also very beneficial. Which alarms are triggered most frequently? How many of them actually required intervention? How many were false positives? These analyses have helped me make alert thresholds more realistic. On “a monitoring system I built for my own site,” I periodically reviewed the top 5 most frequently triggered alarms over the last 30 days and adjusted their thresholds or removed them entirely.

Intelligent Alert Design: What I Did, What I Didn’t

Beyond sifting through noise, I’ve implemented various strategies to make alerts more “intelligent.” This involves much more than just changing thresholds.

1. Dynamic Thresholds and Baselining: Static thresholds quickly become insufficient in situations where system load varies. Instead, I’ve preferred using dynamic thresholds that learn the system’s normal behavior and detect deviations. For time-series data in particular, algorithms that detect deviations from the past 7 or 30-day averages have been effective. In an ERP system, we knew that CPU usage naturally increased during month-end reporting periods. Defining separate thresholds for these periods or allowing the system to learn its own “normal” significantly reduced unnecessary alerts.

2. Alert Correlation and Suppression: It’s common for multiple systems to alarm due to the same root cause. For example, a network outage can cause hundreds of servers to trigger “unreachable” alerts. In such cases, we want to receive a single alert indicating the root cause, the network outage. I’ve set up systems that group similar alarms or suppress others, waiting for the main issue to be resolved. Even for fail2ban patterns, I’ve implemented rate limiting against multiple failed login attempts from a specific IP, preventing repeated alarms from the same IP.

# An example Prometheus alert rule (pseudo-code)
groups:
  - name: my-service-alerts
    rules:
    - alert: HighRequestLatency
      expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{job="my-service"}[5m])) > 0.5
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "High service request latency"
        description: "99th percentile latency on service '{{ $labels.job }}' has been above 0.5 seconds for 5 minutes."

    - alert: ServiceDown
      expr: up{job="my-service"} == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Service unreachable"
        description: "Service '{{ $labels.job }}' has been unreachable for 1 minute."

    # Example rule for alert correlation (actual implementation might be more complex)
    - alert: MultipleServiceFailures
      expr: sum(up{job=~"my-service.*"} == 0) > 3
      for: 2m
      labels:
        severity: major
      annotations:
        summary: "Multiple services are down"
        description: "Multiple 'my-service' components have been unreachable for 2 minutes. Potential root cause: infrastructure issue."
      # When this alarm triggers, we might suppress ServiceDown alarms.
      # In reality, this is done with grouping and inhibition rules in Alertmanager.

3. Alert Prioritization and Notification Channels: Not every alarm has the same urgency. Using immediate calls (pager/SMS) for critical system failures, Slack notifications for less critical but attention-requiring situations, and email for informational or daily summaries ensures that the right channel is used for the right alert. On “a client project,” P1 (critical) alarms directly triggered a call to the mobile phone, while P2 (high) alarms only went to a Slack channel, with action expected within 15 minutes. This ensured the team addressed the right alarm with the right priority.

4. Runbook Integration: Having a runbook that clearly outlines what the team should do when an alarm triggers saves time during panic moments and ensures the correct action is taken. In some cases, automating parts of the steps in the runbook can significantly reduce the Mean Time To Recovery (MTTR). For example, for a disk full alarm, I might trigger an automation script that automatically cleans up old log files or deletes temporary files. I touched upon this topic previously in [my related post on system automation].

Operational Discipline: Culture and Process Change

Reducing pager fatigue isn’t just possible with technical solutions; it also requires changes in operational culture and processes.

1. On-Call Rotation and Responsibility: A clear on-call rotation and clearly defined responsibilities for each shift are important. It should be clear who is responsible for which alarm and when. Furthermore, the alarm load for on-call engineers should be kept within a defined “error budget” or “alarm budget.” If a team consistently exceeds this budget, it’s a sign of a serious problem with the system or alert definitions. At “a manufacturing company,” the alarm load from the previous week and how many of those alarms were real issues versus false positives were always discussed during the weekly on-call rotations.

2. Post-Mortem Culture: Conducting post-mortems after every significant incident not only helps find the root cause of the problem but also allows for drawing lessons to prevent similar incidents in the future. In a post-mortem, issues like why the alarm triggered late, why it provided incorrect information, or why it didn’t trigger at all are examined in detail. This also provides an opportunity for continuous improvement of alerting systems. Once, during a data loss incident I experienced during [my related VPS migration], the post-mortem revealed that disk I/O metrics were insufficient.

3. Regular Alert Review Meetings: Periodically reviewing all alarms (weekly or bi-weekly) is critical for identifying dead or unnecessary alarms and adjusting thresholds. In these meetings, questions like “How many times did this alarm trigger in the last month?”, “What was done when this alarm triggered?”, “Did this alarm truly require intervention?” are asked. On “my own side project’s” monitoring system, I would generate the previous month’s alarm report on the first Monday of each month and discuss it with the team. This allowed us to weed out unnecessary alarms in a timely manner.

🔥 A Trap to Avoid

Simply “silencing” or “disabling” an alarm is a temporary solution that doesn’t address the root cause and can lead to bigger problems in the long run. It’s important to remember that every alarm either points to a problem that needs to be solved or an alert definition that needs to be reconfigured.

4. Automation and Self-Healing Systems: Wherever possible, developing automated solutions for common and known issues significantly reduces pager load. For example, automatically restarting a specific service if it crashes or automatically deleting old logs when disk space exceeds a certain threshold. This allows engineers to focus on more complex issues that require human intervention.

Looking Ahead: The Role of AI and Automation

Today’s technologies, and especially artificial intelligence, are opening new horizons in reducing pager fatigue. My own experiences in AI application architecture and prompt engineering have helped me develop approaches in this area that excite me.

1. Intelligent Anomaly Detection: Instead of traditional threshold-based alerts, AI models can detect much more complex and insidious anomalies by learning the system’s normal behavior. This allows us to identify a potential problem at an early stage, even before a threshold has been breached. For example, in a user’s financial calculator, if an unexpected delay pattern occurs in a specific transaction, an AI model can flag it as an anomaly.

2. Automatic Event Correlation and Root Cause Analysis: AI can analyze thousands of log and metric data points from different systems, automatically correlate events, and suggest potential root causes, simplifying the work of engineers. This aligns with the experience I gained while doing AI-driven production planning in “a manufacturing company’s ERP”; AI can uncover hidden relationships in complex datasets.

3. Intelligent Notification and Escalation: AI can dynamically adjust notification channels and escalation chains based on the severity of an event and the number of users affected. In some cases, it can even suggest or directly apply automated remediation steps based on predefined runbooks. In “an AI-assisted system I built for my own site,” I experimented with automatically restarting certain services based on specific log patterns, and this eliminated the need for human intervention in minor issues.

ℹ️ AI’s Limitations

While AI is a powerful assistant in reducing operational load, it does not replace human intelligence and experience. Especially for rare and complex problems, AI’s predictive capabilities can be limited. Therefore, the goal should be to position AI as an “assistant” and to make operations more efficient, rather than completely eliminating human intervention.

I am trying to increase the reliability of these AI-assisted operational tools by using multi-provider fallback strategies (like Gemini Flash + Groq + Cerebras + OpenRouter). Providing uninterrupted service by switching to another provider when one has an issue is vital for these critical automations.

Conclusion

Pager fatigue is one of the most insidious and destructive problems facing modern operational teams. It’s not just a technical problem but also a cultural issue that affects engineers’ morale, productivity, and ultimately, companies’ operational efficiency. Through years of experience, I’ve seen that there is no single “silver bullet” to combat this issue.

The solution is possible through an integrated approach of intelligent alert design, strong operational discipline, and the use of next-generation AI-assisted tools. I have always operated with the philosophy of “eliminating the cause of the problem rather than solving the problem.” This is a continuous struggle and learning process. It’s important to remember that the best alerting system is one that never triggers an alert but still ensures you are confident that the system is operating healthily. My clear position is: fewer, more meaningful, and more actionable alerts always lead to better operational outcomes.