DEV Community: Gabriel Abreu

RD Inteligente: What the Dominican AI Course Teaches, Asks For, and Says in the Fine Print

Gabriel Abreu — Thu, 24 Sep 2026 23:53:19 +0000

On Thursday, September 10, Dominican President Luis Abinader launched RD Inteligente, the country's National Artificial Intelligence Literacy Program. The goal is to train a million Dominicans for free, and ITLA, the Instituto Tecnológico de Las Américas, runs it.

I went to rdinteligente.do and read what almost nobody reads: the full program, the terms of use and the privacy policy, updated on September 15. Here's what it teaches, what it asks for when you sign up, and what the fine print says.

What it teaches

The program is a three-level ladder, and each level stands on its own: whoever stops at the first one still walks away with something.

Level 1, literacy. Ten hours, the same for everyone, split into six "stops". You get a digital certificate from ITLA.
Level 2, productivity. A track for your line of work, because, as the page puts it, "a nurse and a judge don't need the same thing". You leave with an applied project.
Level 3, specialization. 60 to 120 hours in artificial intelligence, data science, cybersecurity or software development, with a "vendor certification".

These are the six stops of level 1, with their titles translated:

What AI is and what it isn't (1.5 hours)
Talking to an AI (2.5 hours)
Distrusting well (1.5 hours)
Your data and your privacy (1.5 hours)
AI scams: defending yourself (1.5 hours)
Your first real case (1.5 hours)

What I liked most: four and a half of the ten hours are about distrust. Of AI answers, of who you give your data to, and of scams. Stop 5 opens with a scene anyone recognizes: a call at 2:14 a.m., your mom's voice asking you to send money right now, and it isn't your mom. According to the page, thirty seconds of your voice is enough to clone it.

At the launch, the president summed it up: "We don't want to turn a million Dominicans into programmers. We want a million Dominicans to be better at what they already know how to do." The curriculum goes that way.

What it asks for

Your cédula, the Dominican national ID, and an email address. According to the FAQ, it then asks for your date of birth, your province, your neighborhood and the track you want. No phone number, and it costs nothing: not the sign-up, not the content, not the certificate.

The cédula serves two purposes, according to the program itself. One, checking against the voter roll of the Junta Central Electoral that the certificate goes to a real person. Two, one cédula per account, so nobody takes two spots. If the roll doesn't find you, you can enter your details by hand and keep going, but your file stays pending verification and they may ask for proof before issuing the certificate.

There's no password. To log back in you type your cédula and get a one-time code by email. The page says it plainly: your email is the key to your account. If your email doesn't have two-step verification, now is a good time to turn it on.

The level 1 certificate comes when you finish all six stops and answer every check. It's a certificate of participation: according to the terms, it "is not equivalent to an academic degree or a vendor professional certification". List it on your résumé as what it is.

What the fine print says

For a privacy policy, this one is clear: it says what it keeps, who else sees it, where, and for how long. It keeps four kinds of data:

What you type: your cédula, your email and, optionally, the track you identify with.
What the voter roll returns when your cédula is verified: full name, date of birth, sex, nationality, province and municipality. It says it doesn't receive your photo or your voting history.
Your progress through the course: which screens you saw, what you answered and whether you got it right, your progress and your score.
Technical data: your IP address, the date and time of your visits, your browser and your operating system.

On the technical side, it gets several things right:

The cédula is stored encrypted. Only its last four digits are kept next to it, and not even program staff see the full number: it shows up masked, like ***-*****-5678.
No cookies. The session lives in your browser's local storage: if you check "Remember me on this device", it lasts up to ninety days of inactivity; if you don't, it ends when you close the tab.
No third-party analytics or ad cookies, and the videos are self-hosted, so watching them doesn't tell any platform what you're watching.
Technical logs are kept for twelve months.

But there are three things worth knowing before you hand over your cédula:

Your data lives in the United States. The platform and its database are on a server there, and by signing up you authorize that transfer.
The service that verifies your cédula isn't named. The policy says it receives only the cédula, to check it against the voter roll, but it doesn't say which company or institution it is. It does name the other two providers: Microsoft's Azure Front Door, which sees your IP like any network intermediary, and Google Fonts, which gets your IP when the page loads its fonts.
The certificate record is forever. You can ask them to delete your file at any time by writing to info@rdinteligente.do from the email you registered with, a right that Dominican data protection law (Ley 172-13) gives you. But if you already earned a certificate, the record that it was issued is kept permanently.

What doesn't add up yet

Minors. The Presidency's announcement lists high school students among the program's audiences, but the platform requires a cédula, which Dominicans get at 18. The policy admits it: in practice the platform is for adults, and if minors are ever let in, it will be through a different mechanism and with parental permission.
Level 2 hours. The tracks section talks about fifteen hours after the six stops; the level ladder says 25. It adds up if they count the ten common hours, but the page doesn't say.
The level 3 vendor. It promises a "vendor certification" and doesn't say which vendor.
The date for the million. Neither the announcement nor the site says by when.

Who I'd send it to

My mom, my dad and my aunts and uncles, before my developer friends. Level 1 isn't for people who already use these tools every day. It's for people who could lose their savings to a cloned voice on the phone, and for them, stop 5 alone is worth the ten hours.

And one warning straight from the policy: the program never asks for a password, bank details or health information. In its own words: "If any form on the site ever asks you for them, it isn't ours." When something free gets popular, copies show up, and a lookalike link on WhatsApp asking for those things isn't theirs. The site is rdinteligente.do.

Sources: Presidency announcement, September 10, 2026 · RD Inteligente: the program and FAQ · Terms of use · Privacy policy

I write up the things I break and fix at codewithgabo.com.

RD Inteligente: lo que enseña, lo que pide y lo que dice la letra pequeña

Gabriel Abreu — Thu, 24 Sep 2026 23:52:43 +0000

El jueves 10 de septiembre, el presidente Luis Abinader lanzó RD Inteligente, el Programa Nacional de Alfabetización en Inteligencia Artificial. La meta es capacitar gratis a un millón de dominicanos, y lo ejecuta el ITLA.

Me metí a rdinteligente.do y leí lo que casi nadie lee: el programa completo, los términos de uso y la política de privacidad, actualizada el 15 de septiembre. Esto es lo que enseña, lo que te pide para entrar y lo que dice la letra pequeña.

Lo que enseña

El programa es una escalera de tres niveles, y cada uno se sostiene solo: quien se quede en el primero ya se lleva algo.

Nivel 1, alfabetización. Diez horas, iguales para todo el mundo, repartidas en seis "paradas". Deja un certificado digital del ITLA.
Nivel 2, productividad. Una ruta según tu oficio, porque, como dice la página, "una enfermera y un juez no necesitan lo mismo". Deja un proyecto aplicado.
Nivel 3, especialización. De 60 a 120 horas en inteligencia artificial, ciencia de datos, ciberseguridad o desarrollo de software, con "certificación de fabricante".

Las seis paradas del nivel 1 son estas:

Qué es la IA y qué no es (1.5 horas)
Hablarle a una IA (2.5 horas)
Desconfiar bien (1.5 horas)
Sus datos y su privacidad (1.5 horas)
Engaños con IA: defenderse (1.5 horas)
Su primer caso real (1.5 horas)

Lo que más me gustó: de las diez horas, cuatro y media son para desconfiar. De las respuestas de la IA, de a quién le das tus datos y de las estafas. La parada 5 abre con una escena que cualquiera reconoce: una llamada a las 2:14 de la mañana, con la voz de tu mamá pidiendo que le mandes dinero ahora mismo, y no es tu mamá. Según la página, con treinta segundos de tu voz basta para clonarla.

En el lanzamiento, el presidente lo resumió así: "No queremos convertir a un millón de dominicanos en programadores. Queremos que un millón de dominicanos sean mejores en aquello que ya saben hacer". El temario va en esa dirección.

Lo que te pide para entrar

Tu cédula y un correo. Según las preguntas frecuentes, después te piden tu fecha de nacimiento, tu provincia, tu sector y la ruta que quieres seguir. No hace falta número de teléfono, y no cuesta nada: ni la inscripción, ni el contenido, ni el certificado.

La cédula es para dos cosas, según el propio programa. Una, verificar contra el padrón de la Junta Central Electoral que el certificado sale a nombre de una persona real. Dos, que una cédula sea una sola cuenta, para que nadie ocupe dos cupos. Si el padrón no te encuentra, puedes llenar tus datos a mano y seguir con el curso, pero tu expediente queda pendiente de verificación y te pueden pedir una comprobación antes del certificado.

No hay contraseña. Para volver a entrar escribes la cédula y te llega un código de un solo uso al correo. La página lo dice clarito: tu correo es la llave de tu cuenta. Si tu correo no tiene verificación en dos pasos, este es buen momento para ponérsela.

El certificado del nivel 1 sale cuando completas las seis paradas y contestas todas las comprobaciones. Es un certificado de participación: según los términos, "no equivale a un título académico ni a una certificación profesional de fabricante". Ponlo en tu CV como lo que es.

Lo que dice la letra pequeña

Para ser una política de privacidad, esta es clara: dice qué guarda, quién más lo ve, dónde y por cuánto tiempo. Guarda cuatro cosas:

Lo que tú escribes: cédula, correo y, si quieres, la ruta con la que te identificas.
Lo que devuelve el padrón al verificar tu cédula: nombres y apellidos, fecha de nacimiento, sexo, nacionalidad, provincia y municipio. Dice que no recibe tu foto ni tu historial electoral.
Tu paso por el curso: qué pantallas viste, qué respondiste y si acertaste, tu avance y tu puntaje.
Datos técnicos: tu IP, la fecha y hora de tus accesos, tu navegador y tu sistema operativo.

En lo técnico, hace varias cosas bien:

La cédula se guarda cifrada. Junto a ella solo se conservan los últimos cuatro dígitos, y ni el personal del programa ve el número completo: le sale enmascarado, como ***-*****-5678.
No pone cookies. La sesión vive en el almacenamiento local de tu navegador: si marcas "Recordarme en este dispositivo", dura hasta noventa días sin uso; si no, se cierra con la pestaña.
No usa analítica de terceros ni cookies de publicidad, y los videos están en su propio servidor, así que verlos no le avisa a ninguna plataforma qué estás mirando.
Los registros técnicos se guardan doce meses.

Pero hay tres cosas que conviene saber antes de dar la cédula:

Tus datos viven en Estados Unidos. La plataforma y su base de datos están en un servidor allá, y al registrarte autorizas esa transferencia.
El servicio que verifica tu cédula no tiene nombre. La política dice que recibe solo la cédula, para confirmarla contra el padrón, pero no dice qué empresa o institución es. A los otros dos proveedores sí los nombra: Azure Front Door, de Microsoft, que ve tu IP como cualquier intermediario de red, y Google Fonts, que recibe tu IP cuando la página carga sus letras.
La constancia del certificado es para siempre. Puedes pedir que borren tu expediente cuando quieras, escribiendo a info@rdinteligente.do desde el correo con el que te registraste, un derecho que te reconoce la Ley 172-13. Pero si ya sacaste un certificado, la constancia de que se emitió se queda guardada de forma permanente.

Lo que no cuadra todavía

Los menores de edad. El anuncio de la Presidencia pone a los estudiantes de secundaria entre los públicos del programa, pero la plataforma exige cédula, que se saca a los 18 años. La política lo admite: en la práctica es para mayores de edad, y si un día entran los menores, será con otro mecanismo y con permiso de los padres.
Las horas del nivel 2. La sección de rutas habla de quince horas después de las seis paradas; la escalera de niveles dice 25. Cuadra si cuentan las diez del tramo común, pero la página no lo aclara.
El fabricante del nivel 3. Promete "certificación de fabricante" y no dice de cuál.
La fecha del millón. Ni el anuncio ni la página dicen para cuándo.

A quién se lo mandaría

A mi mamá, a mi papá y a mis tíos, antes que a mis panas programadores. El nivel 1 no es para quien ya usa estas herramientas todos los días. Es para la gente que puede perder sus ahorros con una voz clonada en el teléfono, y para esa gente la parada 5 sola ya vale las diez horas.

Y un aviso que sale de la propia política: el programa nunca pide contraseña, ni datos bancarios, ni información de salud. Lo dice así: "Si algún formulario del sitio se los pide alguna vez, no es nuestro". Cuando algo gratis se pone de moda salen las copias, y un link parecido que te llegue por WhatsApp pidiéndote esas cosas no es de ellos. El sitio es rdinteligente.do.

Fuentes: Anuncio de la Presidencia, 10 de septiembre de 2026 · RD Inteligente: el programa y las preguntas frecuentes · Términos de uso · Política de privacidad

I write up the things I break and fix at codewithgabo.com.

The AI Fixed the Bug and Broke Everything Else: How I Review What an Agent Changes

Gabriel Abreu — Thu, 24 Sep 2026 23:52:08 +0000

This week I made an Instagram reel: I ask the AI to fix a bug, "just that one", and it replies that it's done, and that while it was at it, it renamed my variables, updated 14 dependencies, moved the login to another framework and deleted some failing tests. "You're welcome."

It's an exaggerated joke, but every piece of it really happens. In Stack Overflow's 2025 survey, the top frustration with AI tools, cited by 66% of respondents, was "AI solutions that are almost right, but not quite." The second, at 45%, was that debugging AI-generated code takes more time.

The test part isn't made up either. When Anthropic launched Claude 4 in May 2025, one of the improvements it announced was that the new models were 65% less likely than Sonnet 3.7 to use shortcuts or loopholes to complete a task, on the tasks most susceptible to them. If the vendor itself measures it, it happens.

I code with Claude Code (here's how), and these are the five things I do so an agent doesn't hand me a "fixed" that breaks everything else.

1. I ask with a scope and a way out

"Fix the login bug" leaves the door open to anything. I ask like this: what's wrong, where I think it is, what not to touch, and what to do if it has to be touched. For example:

Login fails when the email has uppercase letters. Fix it in auth/login.ts. Don't touch the tests or the dependencies; if you think you need to, stop and tell me why.

The last part is the important one. An agent with no way to tell you "this is bigger than what you asked for" will solve the bigger thing on its own.

2. I look at the size before the change

Before reading a single line, I run this:

git diff --stat

If I asked for one bug and see thirty files, I don't read anything: I ask why. The size of the diff is the first check, and the cheapest.

3. I read the tests first

If the change touches tests, I read those before the code:

git diff -- '*.test.*'

A test that changed along with the code it tests is the signal I look for. Sometimes the change is right, because the behavior changed on purpose. But a test that went from failing to passing because it now expects something else, or one that disappeared, didn't fix anything.

4. I make skipping a check visible

This is the one that has helped me the most. The @codewithgabo reels come out of a suite I built in Remotion, and before exporting, a probe checks that the video changes every two seconds. If it sits still, the export is cancelled. There's a way out, and it's there on purpose: "allowStatic": true in the piece's file. It's one line, and it shows up in the diff by name.

This week, while moving two reels to a new design, the probe flagged a two-second stretch below the minimum, which is 0.6%. The short way out was that line. The agent fixed the reel instead: the closing text now writes itself by hand and gets underlined, and the stretch went up to 1.3%. I don't know if it would have taken the line on another day. What I know is that if it does, I'll see it.

The same goes for any test suite:

Keep .only and .skip out of main. Playwright and Mocha have --forbid-only, Vitest rejects .only in CI by default, and the ESLint plugins for Jest and Vitest ship the no-focused-tests and no-disabled-tests rules.
Give the tests an owner. With a CODEOWNERS file on GitHub and the branch rule that requires code owner review, a change to the tests folder doesn't get in without someone looking at it.
Give the agent rules too. In Claude Code, a PreToolUse hook can block edits to certain paths, like your tests, or make it ask you first.

5. I don't trust how it felt

In July 2025, METR measured 16 experienced developers working on their own projects: with AI they took 19% longer, and afterwards they believed they had been 20% faster. In February 2026, METR published new data, with newer tools, suggesting they now do help. But METR itself said that, because of how the tasks ended up selected, the new data is "only very weak evidence," and it's changing the study's design.

So we still don't really know how much it speeds us up. What did become clear is that how it feels isn't a measurement. That's why the four rules above are checks that don't depend on how it went.

What doesn't change

AI writes fast, and it keeps writing better. Reviewing is still my job, and yours. The agent that "fixed" the bug by deleting the test didn't lie to you: it delivered the only thing it measured as success, a passing test.

Sources: Stack Overflow 2025 Developer Survey, AI section · Anthropic, Claude 4 launch (May 22, 2025) · METR, July 2025 study · METR, February 2026 update · Vitest: allowOnly · Playwright: forbidOnly · ESLint for Jest: no-disabled-tests · ESLint for Vitest: no-disabled-tests · GitHub: CODEOWNERS · Claude Code: hooks

I write up the things I break and fix at codewithgabo.com.

La IA arregló el bug y rompió lo demás: cómo reviso lo que me cambia un agente

Gabriel Abreu — Thu, 24 Sep 2026 23:51:32 +0000

Esta semana hice un reel para Instagram: le pido a la IA que arregle un bug, "solo ese", y me contesta que listo, que de paso renombró mis variables, actualizó 14 dependencias, pasó el login a otro framework y borró unos tests que fallaban. "De nada."

Es un chiste exagerado, pero cada pedazo pasa de verdad. En la encuesta de Stack Overflow de 2025, la frustración número uno con las herramientas de IA, para el 66 % de quienes respondieron, fueron las soluciones que están "casi bien, pero no del todo". La segunda, para el 45 %, fue que depurar código generado por IA toma más tiempo.

Lo de los tests tampoco es invento. Cuando Anthropic lanzó Claude 4, en mayo de 2025, una de las mejoras que anunció fue que los modelos nuevos eran 65 % menos propensos que Sonnet 3.7 a tomar atajos o aprovechar huecos para completar una tarea, en las tareas más propensas a eso. Si el propio fabricante lo mide, es porque pasa.

Yo programo con Claude Code (aquí conté cómo), y estas son las cinco cosas que hago para que un agente no me entregue un "arreglado" que rompe todo lo demás.

1. Pido con alcance y con salida

"Arregla el bug del login" deja la puerta abierta a todo. Yo pido así: qué está mal, dónde creo que está, qué no se toca y qué hacer si hace falta tocarlo. Por ejemplo:

El login falla cuando el correo tiene mayúsculas. Arréglalo en auth/login.ts. No toques los tests ni las dependencias; si crees que hace falta, para y dime por qué.

La última parte es la importante. Un agente que no tiene cómo decirte "esto es más grande de lo que pediste" va a resolver lo grande por su cuenta.

2. Miro el tamaño antes que el cambio

Antes de leer una sola línea, corro esto:

git diff --stat

Si pedí un bug y veo treinta archivos, no leo nada: pregunto por qué. El tamaño del diff es la primera prueba y la más barata.

3. Leo los tests primero

Si el cambio toca tests, esos los leo antes que el código:

git diff -- '*.test.*'

Un test que cambió junto con el código que prueba es la señal que busco. A veces el cambio es correcto, porque el comportamiento cambió a propósito. Pero un test que pasó de fallar a pasar porque ahora espera otra cosa, o que desapareció, no arregló nada.

4. Hago que saltarse una prueba se vea

Esta es la que más me ha servido. Los reels de @codewithgabo salen de una suite que armé en Remotion, y antes de exportar, un probe revisa que el video cambie cada dos segundos. Si se queda quieto, el export se cancela. Hay una salida, y está puesta a propósito: "allowStatic": true en el archivo de la pieza. Es una línea, y queda en el diff con su nombre.

Esta semana, pasando dos reels a un diseño nuevo, el probe marcó un tramo de dos segundos por debajo del mínimo, que es 0.6 %. La salida corta era esa línea. El agente arregló el reel: el texto del final ahora se escribe a mano y se subraya, y el tramo subió a 1.3 %. No sé si otro día habría tomado la línea. Lo que sé es que, si la toma, la veo.

Lo mismo vale para cualquier suite de tests:

Que .only y .skip no lleguen a main. Playwright y Mocha tienen --forbid-only, Vitest no deja pasar un .only en CI por defecto, y los plugins de ESLint para Jest y Vitest traen las reglas no-focused-tests y no-disabled-tests.
Que los tests tengan dueño. Con un archivo CODEOWNERS en GitHub y la regla de rama que exige la revisión del dueño, un cambio en la carpeta de tests no entra sin que alguien lo mire.
Que el agente también tenga reglas. En Claude Code, un hook PreToolUse puede bloquear que edite ciertas rutas, como tus tests, o hacer que te pida permiso antes.

5. No me fío de cómo me sentí

En julio de 2025, METR midió a 16 programadores con experiencia trabajando en sus propios proyectos: con IA tardaron 19 % más, y al terminar creían que habían ido 20 % más rápido. En febrero de 2026, METR publicó datos nuevos, con herramientas más recientes, que apuntan a que ahora sí ayudan. Pero el mismo METR dijo que, por cómo quedaron seleccionadas las tareas, esos datos son "evidencia muy débil", y está cambiando el diseño del estudio.

O sea, todavía no sabemos bien cuánto nos acelera. Lo que sí quedó claro es que lo que uno siente no es una medida. Por eso las cuatro reglas de arriba son chequeos que no dependen de cómo me fue.

Lo que no cambia

La IA escribe rápido, y cada vez escribe mejor. Revisar sigue siendo mi trabajo, y el tuyo. El agente que "arregló" el bug borrando el test no te engañó: cumplió con lo único que midió como éxito, que el test pasara.

Fuentes: Encuesta de Stack Overflow 2025, sección de IA · Anthropic, lanzamiento de Claude 4 (22 de mayo de 2025) · METR, estudio de julio de 2025 · METR, actualización de febrero de 2026 · Vitest: allowOnly · Playwright: forbidOnly · ESLint para Jest: no-disabled-tests · ESLint para Vitest: no-disabled-tests · GitHub: CODEOWNERS · Claude Code: hooks

I write up the things I break and fix at codewithgabo.com.

Generar el XML no es facturar: lo que aprendí construyendo un emisor de e-CF

Gabriel Abreu — Tue, 22 Sep 2026 00:23:40 +0000

El sábado 12 de septiembre construí un emisor de comprobantes fiscales electrónicos, los e-CF de la DGII. Arma el XML de la factura, lo firma con el certificado digital del negocio, lo valida contra el esquema oficial y te imprime la representación con su código QR. Está en mi portafolio, con una demo que cualquiera puede probar.

En su primera pantalla dice, con estas palabras: "usar esta herramienta no te hace emisor electrónico".

Esa frase no es modestia. Es lo más importante que aprendí construyéndolo, y es lo que más se confunde ahora que las fechas están encima: generar el XML no es facturar.

Las fechas son estas:

Grandes locales y medianos: desde el 1 de noviembre solo pueden emitir e-CF. Sus secuencias B valen hasta el 31 de octubre.
Pequeños, micro y no clasificados: el plazo para implementar vence el 15 de noviembre.

Lo que dicen la ley y el reglamento

La Ley 32-23 le dio a cada grupo un plazo contado desde mayo de 2023: 12 meses a los grandes contribuyentes nacionales, 24 a los grandes locales y medianos, y 36 al resto. Así se ha ido cumpliendo:

Grandes nacionales: su plazo venció el 15 de mayo de 2024. Sus comprobantes B se dieron por vencidos el 31 de diciembre de 2025.
Grandes locales y medianos: plazo el 15 de mayo de 2025, prorrogado seis meses para quien ya había solicitado ser emisor. Solo e-CF desde el 1 de noviembre de 2026.
Pequeños, micro y no clasificados: plazo el 15 de mayo de 2026, prorrogado seis meses de forma automática, hasta el 15 de noviembre.

Antes de apostar a otra prórroga, conviene leer dos artículos del reglamento de la ley, el Decreto 587-24. El artículo 8 dice que la prórroga es "de carácter único" y que no puede pasar de seis meses. La de los pequeños ya se dio, y fue de seis meses exactos. El artículo 55 dice que a quien no implemente a tiempo, la DGII le considera vencidos sus comprobantes.

A los dos grupos anteriores, la DGII les anunció después una fecha para dejar la serie B. A los pequeños todavía no se la ha anunciado, y eso no te da tiempo extra: el 15 de noviembre es la fecha para estar autorizado como emisor electrónico. Según el aviso de la prórroga, quien no haya implementado queda expuesto a las sanciones del artículo 27 de la ley, que remite al Código Tributario: multas de 5 a 30 salarios mínimos por incumplir deberes formales.

Lo que construí, y lo que no hace

Mi emisor hace la parte que uno imagina cuando piensa en factura electrónica. Arma el XML de la factura de crédito fiscal (tipo 31) y de la factura de consumo (tipo 32), lo firma, lo valida y lo guarda. Cada comprobante lleva un e-NCF de 13 caracteres: una E, dos dígitos de tipo y diez de secuencia, como E310000000001.

La parte de generar, firmar, validar e imprimir me tomó un sábado, con Claude Code al lado.

Lo que no hace es enviarlo a la DGII, y eso lo cambia todo. La pregunta 1.4.12 de las preguntas frecuentes de la propia DGII lo dice sin rodeos: si Impuestos Internos no recibe el e-CF, este carece de validez tributaria, y el receptor no puede usar el crédito fiscal.

O sea, un PDF con su QR, firmado y validado, que la DGII nunca recibió, no le sirve a tu cliente para su crédito fiscal. Por eso la advertencia va en la primera pantalla y no escondida en el README.

Lo que aprendí armando la parte fácil

La parte "fácil" también tiene trampas que no salen en ningún tutorial.

Un espacio rompe el esquema de la factura de crédito fiscal. Para validar un e-CF se usan los esquemas XSD que publica la DGII. El del tipo 31, la factura que se usa entre empresas, define uno de sus tipos así:

<xs:simpleType name=" IndicadorServicioTodoIncluidoType">

Fíjate en el espacio antes de Indicador. El resto del archivo busca ese tipo por su nombre, sin el espacio. El validador que trae Java recorta el espacio y sigue como si nada. libxml2 no lo hace. Es el motor de xmllint, de lxml en Python, de DOMDocument en PHP y del paquete de Node que usa mi emisor, y se niega a cargar el esquema:

The QName value 'IndicadorServicioTodoIncluidoType' does not resolve to a(n) type definition.
WXS schema e-CF 31 v.1.0.xsd failed to compile

Los esquemas de los tipos 32, 33, 34, 44 y 45 definen el mismo tipo sin el espacio. Hoy lo volví a comprobar contra lo que publica la DGII, y el archivo sigue igual.

Y confieso algo: yo tardé en verlo. En el repo dejé escrito que el esquema usaba un tipo que nunca definía. Sí lo definía, con un espacio de más, y mi búsqueda de texto no lo encontraba por ese mismo espacio.

El ejemplo oficial de la firma trae tres URIs mal escritas. La DGII publica un documento, Firmado de e-CF, con ejemplos de cómo firmar. El XML que muestra la estructura de la firma trae estas tres:

http://www.w3.org/TR/2001/RECxml-c14n-20010315
http://www.w3.org/2001/04/xmldsigmore#rsa-sha256
http://www.w3.org/2000/09/xmldsig#envelope d-signature

Deberían decir REC-xml-c14n, xmldsig-more y enveloped-signature. El ejemplo en TypeScript del mismo documento las escribe bien. Pero si armas tu firma copiando ese XML, no pasa: lo probé con xml-crypto, y contesta que ese algoritmo de canonicalización "is not supported". Además, una firma inválida no es un error barato. Según la pregunta 1.4.18, si la DGII rechaza un e-CF por la firma, ese e-NCF no se puede volver a usar.

El portal le contesta 403 a un script. Los esquemas se bajan del portal de la DGII. Con curl, la respuesta es 403; con el User-Agent de un navegador, 200. Lo volví a probar hoy. Durante un rato di por hecho que la DGII bloqueaba las descargas automáticas, y lo escribí en el plan del proyecto. No las bloquea: filtra por User-Agent. Eso importa porque los esquemas hay que revisarlos antes de cada versión. Los de las notas de débito y de crédito cambiaron el 1 de abril de 2026, casi seis meses después que los demás.

El riesgo de verdad no es el XML, es la secuencia. Dos comprobantes no pueden llevar el mismo número, y no te puedes pasar del rango que te autorizó la DGII. En mi emisor, cada factura se guarda en un archivo que lleva su e-NCF como nombre, y se escribe así:

writeFileSync(`datos/facturas/${encf}.xml`, xml, { flag: 'wx' });

Con wx, la escritura falla si el archivo ya existe. Cumple el mismo papel que un índice único en una base de datos: un duplicado explota en vez de pasar callado. Y el número siguiente se calcula leyendo lo que ya se emitió, no con un contador que se pueda equivocar.

Emitir te obliga a recibir

Esta fue la sorpresa grande, y es la razón de fondo por la que mi emisor no te pone al día.

Uno piensa en la factura electrónica como algo que sale: tu sistema firma y manda. Pero el artículo 18 del reglamento dice que todo emisor electrónico será también receptor electrónico. Tus proveedores que ya emiten e-CF te los van a mandar a ti, y tu sistema tiene que recibirlos, acusar recibo y aprobarlos o rechazarlos.

Por eso, para certificarte con un sistema propio, la DGII te pide tres direcciones de servicios web. Una para recibir los e-CF que te emitan. Otra para recibir las aprobaciones comerciales de lo que tú emites. Y una de autenticación, donde se firma un archivo "semilla" con el certificado digital y se devuelve un token. Después vienen las pruebas de datos, de simulación y de comunicación.

Mi emisor solo escucha en 127.0.0.1, es decir, en la computadora donde corre. Lo hice así a propósito, para que el certificado digital del negocio nunca salga de esa máquina. Para certificarse, tendría que abrirle tres puertas a internet. Esa es la tensión real, y no se resuelve con un XML bien hecho.

Si tienes un negocio: tres caminos y una pregunta

La DGII reconoce tres vías para emitir: un sistema de desarrollo propio, un proveedor de servicios de facturación electrónica certificado, o su Facturador Gratuito.

El Facturador Gratuito no cuesta nada y no te obliga a pasar la certificación. Está pensado para poco volumen: la DGII habla de unas 150 facturas al mes. Igual necesitas RNC, Alta NCF, acceso a la Oficina Virtual y un certificado digital para procedimientos tributarios. Ese certificado va a tu nombre o al de tu representante, no al del contador.
Un proveedor certificado tiene que ofrecerte, por reglamento, el paquete completo: emitir y recibir, los acuses de recibo, las aprobaciones comerciales y el resguardo de tus comprobantes.
El desarrollo propio es el camino de las tres direcciones y las pruebas de arriba. Con 55 días por delante, yo no lo empezaría hoy sin un equipo técnico detrás.

Si vas con un proveedor, hay una pregunta que vale más que la demo: ¿quién guarda mi certificado? El artículo 22 del reglamento permite dos modelos. En uno, la firma se hace en tu infraestructura y el certificado se queda contigo. En el otro, el proveedor te da su software como servicio y custodia tu certificado en la suya. Para eso necesita una interconexión con una entidad de certificación autorizada por el INDOTEL, o un permiso del INDOTEL para firmar en nombre de otros. Ese certificado firma comprobantes a tu nombre ante la DGII. Pregunta en cuál de los dos modelos estás, y pide que te lo pongan por escrito.

Si eres dev

Si te piden "hacer la factura electrónica", pregunta primero qué parte. Generar, firmar y validar el XML me tomó un sábado. Recibir, aprobar, autenticar, pasar la certificación y mantenerte al día cada vez que la DGII cambie un esquema ya es un producto.

Mi emisor sigue diciendo en su primera pantalla que no te hace emisor electrónico. Después de construirlo, es la frase de la que estoy más seguro.

Fuentes: Aviso 14-26, emisión exclusiva de e-CF · Aviso 06-26, prórroga de pequeños, micro y no clasificados · Aviso 12-25 · Aviso 25-25 · Ley 32-23 · Decreto 587-24 · Preguntas frecuentes de e-CF · Preguntas frecuentes del Facturador Gratuito · Documentación técnica y esquemas XSD · El código del emisor

I write up the things I break and fix at codewithgabo.com.

Generating the XML Isn't Invoicing: What I Learned Building a Dominican E-Invoice Issuer

Gabriel Abreu — Tue, 22 Sep 2026 00:23:04 +0000

On Saturday, September 12, I built an issuer of electronic fiscal receipts, the e-CF that the Dominican tax authority, the DGII, requires. It builds the invoice XML, signs it with the business's digital certificate, validates it against the official schema and prints the invoice with its QR code. It is in my portfolio, with a demo anyone can try.

Its first screen says, in Spanish, that using it does not make you an emisor electrónico, an authorised electronic issuer.

That sentence is not modesty. It is the most important thing I learned building it, and it is exactly what gets confused now that the deadlines are close: generating the XML is not invoicing.

These are the deadlines:

Large local and medium taxpayers: from November 1 they can only issue e-CF. Their non-electronic "B" sequences are valid until October 31.
Small, micro and unclassified taxpayers: the deadline to implement falls on November 15.

What the law and the regulation say

Law 32-23 gave each group a deadline counted from May 2023: 12 months for large national taxpayers, 24 for large local and medium ones, and 36 for everyone else. This is how it has played out:

Large national taxpayers: their deadline was May 15, 2024. Their B receipts were declared expired on December 31, 2025.
Large local and medium taxpayers: deadline May 15, 2025, extended six months for those who had already applied to become issuers. Only e-CF from November 1, 2026.
Small, micro and unclassified: deadline May 15, 2026, extended six months automatically, to November 15.

Before betting on another extension, it is worth reading two articles of the law's regulation, Decree 587-24. Article 8 says the extension is a one-time measure and cannot exceed six months. The small taxpayers already got theirs, and it was exactly six months. Article 55 says that for anyone who does not implement in time, the DGII treats their receipts as expired.

The two earlier groups were later given a date to stop using the B series. The small ones have not been given one yet, and that buys no extra time: November 15 is the date to be authorised as an electronic issuer. According to the extension notice, anyone who has not implemented faces the penalties in article 27 of the law, which points to the Tax Code: fines of 5 to 30 minimum wages for breaching formal duties.

What I built, and what it does not do

My issuer does the part people picture when they think of e-invoicing. It builds the XML for the tax credit invoice (type 31) and the consumer invoice (type 32), signs it, validates it and stores it. Each receipt carries a 13-character e-NCF: an E, two digits for the type and ten for the sequence, as in E310000000001.

Generating, signing, validating and printing took me a Saturday, with Claude Code alongside.

What it does not do is send anything to the DGII, and that changes everything. Question 1.4.12 of the DGII's own FAQ says it bluntly: if the tax authority never receives the e-CF, it has no tax validity, and the buyer cannot claim the tax credit.

In other words, a PDF with its QR code, signed and validated, that the DGII never received is useless to your customer's tax credit. That is why the warning is on the first screen and not buried in the README.

What I learned building the easy part

The "easy" part has traps of its own, and no tutorial mentions them.

One space breaks the schema for the tax credit invoice. An e-CF is validated against XSD schemas the DGII publishes. The one for type 31, the invoice businesses use with each other, defines one of its types like this:

<xs:simpleType name=" IndicadorServicioTodoIncluidoType">

Look at the space before Indicador. The rest of the file looks the type up by its name, without the space. The validator that ships with Java trims the space and carries on. libxml2 does not. It is the engine behind xmllint, lxml in Python, DOMDocument in PHP and the Node package my issuer uses, and it refuses to load the schema:

The QName value 'IndicadorServicioTodoIncluidoType' does not resolve to a(n) type definition.
WXS schema e-CF 31 v.1.0.xsd failed to compile

The schemas for types 32, 33, 34, 44 and 45 define the same type without the space. I checked again today against what the DGII publishes, and the file is unchanged.

And a confession: I was slow to see it. What I wrote in the repo is that the schema used a type it never defined. It did define it, with one space too many, and my text search could not find it because of that same space.

The official signing example has three misspelled URIs. The DGII publishes a document, Firmado de e-CF, with examples of how to sign. The XML that shows the structure of the signature has these three:

http://www.w3.org/TR/2001/RECxml-c14n-20010315
http://www.w3.org/2001/04/xmldsigmore#rsa-sha256
http://www.w3.org/2000/09/xmldsig#envelope d-signature

They should read REC-xml-c14n, xmldsig-more and enveloped-signature. The TypeScript example in the same document spells them correctly. But if you build your signature by copying that XML, it fails: I tried it with xml-crypto, and it answers that the canonicalisation algorithm "is not supported". A bad signature is not a cheap mistake, either. According to question 1.4.18, if the DGII rejects an e-CF over its signature, that e-NCF can never be used again.

The portal answers a script with a 403. The schemas are downloaded from the DGII's portal. With curl, the answer is 403; with a browser's User-Agent, 200. I tried it again today. For a while I assumed the DGII blocked automated downloads, and I wrote that into the project plan. It does not block them: it filters by User-Agent. That matters because the schemas have to be checked before every release. The ones for debit and credit notes changed on April 1, 2026, almost six months after the rest.

The real risk is not the XML, it is the sequence. Two receipts cannot share a number, and you cannot go past the range the DGII authorised. In my issuer, each invoice is saved to a file named after its e-NCF, written like this:

writeFileSync(`datos/facturas/${encf}.xml`, xml, { flag: 'wx' });

With wx, the write fails if the file already exists. It does the job of a unique index in a database: a duplicate blows up instead of slipping through quietly. And the next number is worked out by reading what was already issued, not from a counter that can be wrong.

Issuing means receiving

This was the big surprise, and it is the underlying reason my issuer does not get you compliant.

You think of e-invoicing as something that goes out: your system signs and sends. But article 18 of the regulation says that every electronic issuer is also an electronic receiver. Your suppliers who already issue e-CF will send theirs to you, and your system has to receive them, acknowledge receipt, and approve or reject them.

That is why, to certify your own system, the DGII asks for three web service addresses. One to receive the e-CF issued to you. Another to receive the commercial approvals of what you issue. And one for authentication, where a "seed" file is signed with the digital certificate and a token comes back. Then come the data, simulation and communication tests.

My issuer only listens on 127.0.0.1, meaning the computer it runs on. I did that on purpose, so the business's digital certificate never leaves that machine. To be certified, it would have to open three doors to the internet. That is the real tension, and a well-formed XML does not resolve it.

If you run a business: three paths and one question

The DGII recognises three ways to issue: your own system, a certified e-invoicing service provider, or its free invoicing tool, the Facturador Gratuito.

The Facturador Gratuito costs nothing and does not require certification. It is meant for low volume: the DGII talks about roughly 150 invoices a month. You still need a tax ID, authorisation to issue receipts, access to the DGII's online office and a digital certificate for tax procedures. That certificate goes in your name or your representative's, not your accountant's.
A certified provider has to offer you, by regulation, the whole package: issuing and receiving, acknowledgements of receipt, commercial approvals and storage of your receipts.
Building your own is the path with the three addresses and the tests above. With 55 days left, I would not start it today without a technical team behind it.

If you go with a provider, there is one question worth more than the demo: who holds my certificate? Article 22 of the regulation allows two models. In one, signing happens on your infrastructure and the certificate stays with you. In the other, the provider sells its software as a service and keeps your certificate on its own infrastructure. For that it needs an interconnection with a certification entity authorised by INDOTEL, the Dominican telecom regulator, or an INDOTEL licence to sign on behalf of others. That certificate signs receipts in your name before the DGII. Ask which of the two models you are in, and get it in writing.

If you are a developer

If someone asks you to "do the e-invoicing", ask which part first. Generating, signing and validating the XML took me a Saturday. Receiving, approving, authenticating, passing certification and keeping up every time the DGII changes a schema is a product.

My issuer still says on its first screen that it does not make you an electronic issuer. Having built it, that is the sentence I am most sure of.

Sources (in Spanish): Notice 14-26, e-CF only · Notice 06-26, extension for small, micro and unclassified taxpayers · Notice 12-25 · Notice 25-25 · Law 32-23 · Decree 587-24 · e-CF FAQ · Facturador Gratuito FAQ · Technical documentation and XSD schemas · The issuer's code

I write up the things I break and fix at codewithgabo.com.

La próxima filtración llegó en cuatro días: cómo leer lo de la Policía

Gabriel Abreu — Thu, 17 Sep 2026 18:00:00 +0000

El 15 de septiembre publiqué un análisis de lo de Claro con una sección titulada "cómo leer la próxima afirmación de filtración". Escribí que iba a haber otra.

Llegó hoy. Cuatro días después de la de Claro.

Una cuenta que monitorea canales de cibercrimen, VECERT Analyzer, publicó una alerta: alguien compartió un enlace de descarga que supuestamente contiene registros del Sistema Policial de Gestión de Denuncias, el SPGD de la Policía Nacional. Un archivo de 10,000 líneas en una plataforma de alojamiento temporal.

La misma alerta lo dice en su primera línea: estado, no confirmado. Hay evidencia visible —el enlace existe, y quien lo publicó adjuntó el escudo de la institución— pero la autenticidad de los registros, su vigencia y el alcance de cualquier compromiso están sin verificar.

Al momento de escribir esto no encontré un solo medio dominicano cubriéndolo, ni una respuesta de la Policía.

Así que voy a hacer lo que dije que había que hacer: pasarle los cinco filtros, en público, sin saber de antemano qué sale.

Por qué esta importa más que la de Claro

Antes de los filtros, el contexto. El SPGD no es una lista de clientes.

Según la propia Policía Nacional, al sistema se migraron más de cuatro millones de registros, y se alimenta desde más de 170 centros de recepción en todo el país. El portal público acepta denuncias oficiales, denuncias anónimas y denuncias de violencia de género, y le pide al ciudadano sus datos personales, el relato detallado del hecho y sus datos de contacto.

Ese mismo portal hace una promesa, textual: "Se garantizará la protección de la identidad de la persona denunciante y/o de la persona afectada."

Una lista de teléfonos filtrada facilita estafas. Una base de denuncias identifica a quien denunció, a quién denunció, y qué contó. Si la alegación fuera cierta, lo que se habría roto es esa promesa exacta.

Por eso este caso exige más cuidado que el anterior, no menos. Y por eso hay algo que va primero que cualquier filtro:

No busques ese archivo. No lo bajes. No lo compartas. Si es falso, es un anzuelo — un archivo de origen criminal que alguien quiere que abras. Si es real, adentro hay personas que denunciaron a un agresor creyendo que nadie más lo sabría. Yo no lo descargué para escribir esto, y nada en este análisis lo necesita.

Filtro 1: ¿hay muestra verificable?

Hay más que en el caso de Claro: no una captura, sino un enlace a un archivo. Pero "existe un archivo" y "el archivo es lo que dicen" son afirmaciones distintas, y nadie independiente ha verificado la segunda. La propia alerta lo reconoce.

Veredicto: evidencia de que alguien publicó algo. Nada más.

Filtro 2: ¿los campos son internos o de catálogo?

La alerta no dice qué campos trae el archivo. No hay esquema, no hay muestra descrita, no hay nada contra qué comparar. Este filtro es el que más separa una filtración real de un refrito, y aquí no se puede ni empezar a aplicar.

Veredicto: sin datos.

Filtro 3: ¿los datos son frescos?

Tampoco se sabe. Y aquí hay una trampa específica de este sistema: como al SPGD se migraron millones de registros históricos, datos viejos no probarían que sea falso — el sistema real los contiene. Lo que haría falta para probar acceso actual son registros recientes, y nadie ha mostrado ninguno.

Veredicto: sin datos.

Filtro 4: ¿alguien lo cruzó con filtraciones anteriores?

No que se haya publicado. Con una aritmética sencilla encima: 10,000 líneas contra más de cuatro millones de registros es el 0.25% del sistema. Eso puede ser una muestra para probar acceso, puede ser todo lo que alguien tiene, o puede ser un recorte de otra cosa. Las tres explicaciones producen exactamente el mismo enlace.

Veredicto: sin datos.

Filtro 5: ¿quién lo está contando?

Un agregador. Que, para su crédito, etiqueta la alerta como no confirmada desde la primera línea. El riesgo viene después: cada vez que alguien la reenvíe, esa etiqueta es lo primero que se cae. "Alegada filtración, sin confirmar" se convierte en "hackearon a la Policía" en dos reenvíos.

Y un detalle que vale anotar: el alias al que se atribuye esta publicación difiere en un carácter del que los medios atribuyeron a lo de Claro. Puede ser la misma persona, un error de transcripción de alguien, o un imitador montado en el nombre del momento. Yo no lo sé, y quien te diga que sí tampoco lo sabe.

Veredicto: fuente honesta sobre su propia incertidumbre. Los reenvíos no lo serán.

El marcador

Cinco filtros: uno con evidencia parcial, tres sin datos, uno que describe al mensajero. Eso no es "falso". Es "no se sabe". Y no se sabe es una respuesta completa — la única honesta hoy.

Qué hacer si tú denunciaste algo

Aquí el consejo no es el de Claro. No hay segundo factor que mover.

Si te llaman "de la Policía" con detalles de tu caso, eso ya no prueba nada. Conocer tu denuncia no demuestra que quien llama es un agente. Si te piden dinero, datos o que vayas a algún sitio: cuelga, y verifica tú en tu destacamento o por los canales oficiales.

Si denunciaste a un agresor y esto te preocupa, la Línea Mujer del Ministerio de la Mujer es el *212: gratuita, confidencial, 24 horas, y se marca desde cualquier celular de Altice, Claro o Viva. No esperes a que alguien confirme nada para llamar.

Y no vayas a buscar si apareces en el archivo. Es la reacción natural y es exactamente la que aprovecha un anzuelo.

Lo que nos toca a los que construimos sistemas

La recomendación técnica de la alerta es la parte más útil, y aplica a cualquiera: auditar los registros de acceso para identificar qué usuario o qué IP hizo consultas masivas o exportó 10,000 registros recientemente.

La pregunta incómoda es si tu sistema puede responderla. ¿Queda registrado quién exporta? ¿Salta una alerta cuando una cuenta lee diez mil filas en una tarde? Un sistema con más de 170 puntos de entrada tiene más de 170 conjuntos de credenciales; la pregunta nunca es si una se va a comprometer, sino cuánto puede leer antes de que alguien lo note.

Esa capacidad —poder decir en horas "sí fue nuestro" o "no lo fue"— es la misma que pedí en el post de Claro. Cuatro días después vuelve a ser la pieza que falta.

Fuentes: la alerta es de VECERT Analyzer, marcada como no confirmada por la propia cuenta · Policía Nacional, sobre el SPGD · Portal de denuncias · Línea Mujer *212

I write up the things I break and fix at codewithgabo.com.

The Next Leak Claim Took Four Days: Reading the Police One

Gabriel Abreu — Thu, 17 Sep 2026 17:57:52 +0000

On September 15 I published an analysis of the Claro claim with a section called "how to read the next leak claim." I wrote that there would be another one.

It arrived today. Four days after the Claro one.

An account that monitors cybercrime channels, VECERT Analyzer, published an alert: someone shared a download link that allegedly contains records from the Dominican National Police's complaint management system, the SPGD. A 10,000-line file on a temporary hosting platform.

The alert itself says it in its first line: status, unconfirmed. There is visible evidence — the link exists, and whoever posted it attached the institution's crest — but the authenticity of the records, how current they are, and the extent of any compromise are all unverified.

At the time of writing I could not find a single Dominican outlet covering it, nor a response from the Police.

So I am going to do what I said should be done: run the five filters, in public, without knowing in advance what comes out.

Why this one matters more than Claro

Before the filters, the context. The SPGD is not a customer list.

According to the National Police itself, more than four million records were migrated into the system, and it is fed from more than 170 reception centres across the country. The public portal accepts official complaints, anonymous tips and gender violence reports, and asks the citizen for personal data, a detailed account of what happened, and contact details.

That same portal makes a promise, verbatim: "Se garantizará la protección de la identidad de la persona denunciante y/o de la persona afectada" — the identity of the person reporting, and of the person affected, will be protected.

A leaked phone list makes scams easier. A complaints database identifies who reported, whom they reported, and what they said. If the claim were true, that exact promise is what would have been broken.

Which is why this case calls for more care than the last one, not less. And why one thing comes before any filter:

Do not look for that file. Do not download it. Do not share it. If it is fake, it is bait — a file of criminal origin that someone wants you to open. If it is real, inside it are people who reported an abuser believing nobody else would know. I did not download it to write this, and nothing in this analysis needs it.

Filter 1: is there a verifiable sample?

There is more than in the Claro case: not a screenshot, but a link to a file. But "a file exists" and "the file is what they say" are different claims, and no independent party has verified the second. The alert itself acknowledges that.

Verdict: evidence that someone posted something. Nothing more.

Filter 2: are the fields internal or catalogue?

The alert does not say which fields the file contains. No schema, no described sample, nothing to compare against. This is the filter that best separates a real leak from a rehash, and here it cannot even begin.

Verdict: no data.

Filter 3: is the data fresh?

Also unknown. And there is a trap specific to this system: because millions of historical records were migrated into the SPGD, old data would not prove the claim false — the real system contains it. What would prove current access is recent records, and nobody has shown any.

Verdict: no data.

Filter 4: has anyone cross-checked it against previous leaks?

Not that anyone has published. With one piece of arithmetic on top: 10,000 lines against more than four million records is 0.25% of the system. That could be a sample to prove access, it could be everything someone has, or it could be a slice of something else. All three explanations produce exactly the same link.

Verdict: no data.

Filter 5: who is telling you?

An aggregator. One that, to its credit, labels the alert unconfirmed from its first line. The risk comes afterwards: every time someone forwards it, that label is the first thing to fall off. "Alleged leak, unconfirmed" becomes "the Police got hacked" within two forwards.

And a detail worth writing down: the alias this post is attributed to differs by one character from the one the press attributed to the Claro claim. It could be the same person, someone's transcription error, or an imitator riding the name of the moment. I do not know, and whoever tells you they do does not know either.

Verdict: a source that is honest about its own uncertainty. The forwards will not be.

The scoreboard

Five filters: one with partial evidence, three with no data, one that describes the messenger. That is not "false." It is "unknown." And unknown is a complete answer — the only honest one today.

What to do if you filed a complaint

The advice here is not the Claro advice. There is no second factor to move.

If "the Police" call you with details of your case, that no longer proves anything. Knowing your complaint does not show the caller is an officer. If they ask for money, data, or for you to go somewhere: hang up, and verify yourself at your station or through official channels.

If you reported an abuser and this worries you, the Ministry of Women's Línea Mujer is *212: free, confidential, 24 hours, dialled from any Altice, Claro or Viva mobile in the Dominican Republic. Do not wait for anyone to confirm anything before calling.

And do not go looking to see whether you are in the file. It is the natural reaction, and it is exactly the one bait relies on.

What this means for those of us who build systems

The alert's technical recommendation is its most useful part, and it applies to everyone: audit the access logs to identify which user or IP recently ran mass queries or exported 10,000 records.

The uncomfortable question is whether your system could answer it. Is it logged who exports? Does an alert fire when one account reads ten thousand rows in an afternoon? A system with more than 170 points of entry has more than 170 sets of credentials; the question is never whether one gets compromised, but how much it can read before anyone notices.

That capability — being able to say within hours "yes, that was ours" or "no, it was not" — is the same one I asked for in the Claro post. Four days later it is the missing piece again.

Sources: the alert is from VECERT Analyzer, marked unconfirmed by the account itself · National Police, on the SPGD · Complaints portal · Línea Mujer *212

I write up the things I break and fix at codewithgabo.com.

Lo de Claro: qué se sabe, qué no, y qué hacer igual

Gabriel Abreu — Wed, 16 Sep 2026 17:16:48 +0000

El 13 de septiembre apareció en un foro la afirmación de que alguien había accedido a los sistemas de Claro en República Dominicana y sacado una base con 2,889,256 registros de clientes. La cifra se repitió rápido, amplificada desde X, y en cuestión de horas medio país la daba por hecha.

Vale la pena separar dos cosas que se mezclaron enseguida: lo que se afirmó y lo que está comprobado. No son lo mismo, y la diferencia cambia qué deberías hacer tú.

Qué se afirmó

Según la publicación, cada registro incluiría:

Número de identificación
Número de teléfono
Información de la suscripción
Estado de la cuenta
Categoría del plan
Fecha de activación
Ciclo de facturación
Códigos internos
ICCID, el identificador único de cada tarjeta SIM

Ese último campo es el que más dice. El ICCID no es un dato de mercadeo: identifica una SIM en concreto.

Qué no está comprobado

Prácticamente todo lo demás.

La afirmación no se ha podido comprobar de forma independiente. Las muestras difundidas no permiten establecer por sí solas el origen de los datos, ni demuestran que la información sea reciente, completa, ni que salga de los sistemas de la empresa.

Claro Dominicana no ha confirmado públicamente ningún incidente. Al momento de escribir esto tampoco aparecen investigaciones ni notificaciones anunciadas por autoridades dominicanas.

Así que el estado real es: una alegación difundida en redes, no una filtración confirmada.

Por qué eso no te deja tranquilo

Aquí es donde casi todo el mundo saca la conclusión equivocada, en una dirección o en la otra.

Unos leen "no está confirmado" y siguen igual. Otros leen la cifra y entran en pánico. Las dos reacciones tratan la incertidumbre como si fuera información.

Míralo por el costo:

Si la filtración es falsa y tú moviste tu autenticación de dos pasos fuera del SMS, perdiste veinte minutos.
Si es real y esperaste la confirmación oficial, esperaste justo durante la ventana en que esos datos valen más.

No es simétrico. Y la confirmación, cuando llega, suele llegar tarde: primero hay que verificar, luego decidir qué se comunica, y eso toma días o semanas. Mientras tanto, lo que estuviera circulando ya circuló.

La ausencia de confirmación no es confirmación de ausencia.

Qué haría alguien con esos datos, si fueran reales

No hace falta imaginar escenarios de película. Con cédula, teléfono, plan y ciclo de facturación, dos ataques normales se vuelven mucho más fáciles.

El primero es la llamada que sabe cosas de ti. El esquema de siempre —"le llamamos de su compañía telefónica"— falla porque el que llama no sabe nada. Con esos campos sí sabe: tu nombre, tu cédula, qué plan tienes y cuándo te facturan. Toda la pregunta de seguridad que tu banco te hace por teléfono está en esa lista.

El segundo es el cambio de SIM. Si alguien convence a un punto de servicio de que es tú y se lleva tu número a otra SIM, hereda tus mensajes. Y ahí es donde duele: el SMS sigue siendo el segundo factor de casi todo en el país. Tu banco, tu correo, tus redes. Quien controla tu número puede pedir el código de recuperación de todo lo demás.

Por eso el dato del ICCID no es un detalle técnico aburrido. Es el que convierte una lista de clientes en una lista de objetivos.

Qué hacer esta semana

Ninguna de estas cosas depende de que la filtración se confirme.

Saca tu segundo factor del SMS. Correo, banco, redes: donde se pueda, usa una app de autenticación. Es el cambio con más efecto por minuto invertido, y es el único que te protege si tu número deja de ser tuyo.

Pregunta en tu compañía qué hace falta para cambiar tu número de SIM. Si la respuesta es "una llamada", eso es el problema. Pide que exija presencia física o una clave adicional, si lo ofrecen.

Ponle PIN a la SIM. Es el menú de seguridad del teléfono, toma un minuto, y bloquea el caso simple de que te roben el equipo y saquen la tarjeta.

Cambia tu regla mental sobre quién te llama. Que alguien sepa tu cédula ya no prueba nada. Nunca fue una buena prueba; ahora ni siquiera es una mala. Si te llaman de tu banco, cuelga y llama tú al número de la tarjeta.

Y nunca leas un código en voz alta. Ningún banco, ninguna telefónica y ninguna app te va a pedir por teléfono el código que te acaba de llegar.

Lo que nos toca a los que construimos software

Si tú haces sistemas para clientes dominicanos, esto cambia dos supuestos.

El primero: la cédula y el teléfono no son secretos. Nunca lo fueron del todo, pero cualquier sistema que verifique identidad preguntando la cédula está haciendo teatro. Si tu recuperación de cuenta se apoya en "dime tu número de documento", tu recuperación de cuenta es pública.

El segundo: el OTP por SMS es un factor prestado. No lo controlas tú, lo controla la operadora, y su seguridad es la de su punto de atención al cliente. Si tu app protege dinero o datos sensibles, ofrece al menos la opción de una app de autenticación.

Y hay un tercero, más incómodo, que aplica aunque este caso resulte falso: tú también estás a un export de distancia. Casi toda base de datos de clientes puede volcarse completa desde adentro. Las preguntas útiles no son de firewall:

¿Cuántos campos guardas que nunca usas? Cada uno es superficie.
¿Quién puede exportar la tabla de clientes completa, y queda registrado?
Si mañana aparece un volcado con tu esquema, ¿podrías decir en horas si es tuyo y de cuándo?

Esa última es la que separa una respuesta creíble de un silencio de dos semanas.

El marco legal, y su hueco

En República Dominicana la referencia es la Ley 172-13, del 13 de diciembre de 2013, sobre protección de datos de carácter personal. Lo que sí establece con claridad:

El tratamiento de datos exige consentimiento previo, libre, inequívoco y específico del titular, salvo las excepciones que la propia ley contempla.
Quien trata datos debe adoptar medidas técnicas y organizativas para evitar accesos no autorizados o alteraciones.
Tú tienes derecho a que rectifiquen, actualicen o supriman tus datos, y el responsable tiene un plazo máximo de diez días hábiles desde tu reclamo.

Lo que no encontré en las fuentes que revisé es una obligación explícita de notificar una brecha a los afectados. Si existe en algún reglamento posterior, no me topé con ella, y me parece relevante decirlo así en vez de afirmar lo contrario.

Ese hueco explica bastante. Cuando no hay un reloj legal corriendo, "no comentamos" es una estrategia viable. En Europa no lo sería: el reglamento allá obliga a notificar en 72 horas. Aquí el incentivo apunta al otro lado.

Cómo funciona un cambio de SIM fraudulento

Vale la pena entenderlo, porque la defensa se vuelve obvia cuando ves el orden de los pasos.

Quien ataca ya sabe quién eres. Nombre, cédula, número, plan. Con eso no necesita adivinar nada.
Llama o se presenta como tú y pide un reemplazo de SIM: que se le perdió el teléfono, que la tarjeta se dañó. Responde las preguntas de verificación porque las respuestas están en la lista.
Tu teléfono se queda sin señal. Esa es la única señal de alarma que recibes, y es fácil confundirla con un problema de red. Ese detalle es el que hace que el ataque funcione de noche.
Ahora tus SMS llegan a otro equipo. Entra a tu correo con "olvidé mi contraseña", recibe el código, y desde el correo cae todo lo demás.

Fíjate dónde está el punto débil: no es tu contraseña, ni tu teléfono, ni siquiera tus datos. Es el mostrador donde alguien decide si el que llama eres tú. Tu seguridad depende del entrenamiento de una persona que no conoces, que atiende a cien clientes al día.

Por eso mover el segundo factor fuera del SMS es la única defensa que no depende de esa persona.

Cómo leer la próxima afirmación de filtración

Va a haber otra. Conviene tener criterios antes, no durante.

¿Hay muestra verificable? No "capturas de pantalla": registros que alguien independiente pueda cruzar con datos reales conocidos. Una captura no prueba origen; un CSV con mil filas que cuadran, sí.

¿Los campos son internos o de catálogo? Un teléfono y un nombre pueden salir de cualquier lado. Un ICCID, un código interno o un ciclo de facturación no aparecen en un formulario público. Los campos que solo existen dentro del sistema son la parte difícil de falsificar.

¿Los datos son frescos? La pregunta que más filtraciones tumba. Si en la muestra no hay una sola línea activada este año, probablemente estás viendo datos viejos, de otra brecha, revendidos con etiqueta nueva.

¿Alguien cruzó la muestra con filtraciones anteriores? Reempaquetar volcados viejos y venderlos como nuevos es un negocio, no una excepción. Es la explicación más aburrida y por eso la más frecuente.

¿Y quién lo está contando? Una cuenta que agrega filtraciones no es una fuente que las verifica. Amplificar y comprobar son dos oficios distintos.

Con esos cinco filtros, la mayoría de los sustos de internet se resuelven solos en un día.

Qué debería publicar una empresa para cerrar el tema

Aquí hay una asimetría que casi nadie nota: la empresa es la única que puede cerrar esto barato.

Quien afirma tener los datos no puede probar el origen sin exponerse. Quien los revisa desde fuera solo puede decir "parece plausible". Pero la empresa tiene el esquema de su propia base. Sabe si un campo llamado como aparece en la muestra existe en sus sistemas, sabe si ese formato de código interno es suyo, y sabe si las fechas de activación corresponden a su historia.

Un comunicado útil tiene tres frases:

Revisamos la muestra, y estos campos corresponden o no corresponden a nuestro esquema.
Si corresponden, este es el alcance y estas son las cuentas afectadas.
Esto es lo que debes hacer tú, con instrucciones concretas.

Un comunicado inútil dice que la seguridad de los clientes es prioritaria.

El silencio tiene un costo que no se ve en el momento: deja a todo el mundo gestionando el peor caso por su cuenta. Y deja vivo el rumor, que es más difícil de matar en dos semanas que en dos días.

Cómo termina esto, probablemente

Hay tres finales posibles. Que alguien verifique las muestras y resulten auténticas. Que se demuestre que son datos viejos, recombinados de filtraciones anteriores —pasa más de lo que uno cree—. O que no pase nada y la historia se apague en dos semanas sin que nadie sepa.

El tercero es el más probable. Y es el peor, porque deja a todo el mundo con la misma duda y sin ninguna razón para cambiar nada.

Por eso el consejo de arriba no depende del final. Mover tu segundo factor fuera del SMS te conviene igual si esto resultó ser humo, igual si resultó ser cierto, e igual la próxima vez que aparezca una lista con tu nombre.

Fuentes: N Digital · EyR · Ley 172-13, texto oficial

I write up the things I break and fix at codewithgabo.com.

The Claro Claim: What Is Known, What Is Not, and What to Do Anyway

Gabriel Abreu — Wed, 16 Sep 2026 17:16:12 +0000

On September 13 a forum post claimed that someone had broken into Claro's systems in the Dominican Republic and taken a database of 2,889,256 customer records. The number travelled fast, amplified from X, and within hours half the country was treating it as fact.

Two things got merged immediately that are worth pulling apart: what was claimed, and what has been verified. They are not the same, and the difference changes what you should do.

What was claimed

According to the post, each record would include:

National identification number
Phone number
Subscription information
Account status
Plan category
Activation date
Billing cycle
Internal codes
ICCID, the unique identifier of each SIM card

That last field is the one that says the most. An ICCID is not a marketing attribute: it identifies one specific SIM.

What has not been verified

Nearly everything else.

The claim could not be verified independently. The circulated samples do not establish the origin of the data on their own, and they do not show the information is recent, complete, or taken from the company's systems.

Claro Dominicana has not publicly confirmed any incident. At the time of writing, no Dominican authority has announced an investigation or a notification either.

So the honest status is: an allegation circulating on social media, not a confirmed breach.

Why that does not let you relax

This is where most people draw the wrong conclusion, in one direction or the other.

Some read "unconfirmed" and carry on. Others read the number and panic. Both reactions treat uncertainty as if it were information.

Look at the cost instead:

If the leak is fake and you moved your two-factor authentication off SMS, you lost twenty minutes.
If it is real and you waited for official confirmation, you waited during exactly the window when that data is worth the most.

That is not symmetric. And confirmation, when it arrives, usually arrives late: first someone has to verify, then decide what to say, and that takes days or weeks. Whatever was circulating has already circulated.

Absence of confirmation is not confirmation of absence.

What someone could do with that data, if it were real

No need to imagine film plots. With an ID number, a phone, a plan and a billing cycle, two ordinary attacks get much easier.

The first is the call that knows things about you. The old script — "we're calling from your phone company" — fails because the caller knows nothing. With those fields they do: your name, your ID, which plan you have, when you get billed. Every security question your bank asks over the phone is on that list.

The second is the SIM swap. If someone convinces a service desk that they are you and moves your number to another SIM, they inherit your messages. And that is where it hurts: SMS is still the second factor for almost everything here. Your bank, your email, your accounts. Whoever controls your number can request the recovery code for everything else.

That is why the ICCID is not a boring technical detail. It is what turns a customer list into a target list.

How a fraudulent SIM swap actually works

Worth understanding, because the defence becomes obvious once you see the order of the steps.

The attacker already knows who you are. Name, ID, number, plan. Nothing to guess.
They present as you and ask for a replacement SIM: lost phone, damaged card. They answer the verification questions because the answers are on the list.
Your phone loses signal. That is the only alarm you get, and it is easy to mistake for a network problem. That detail is why the attack works at night.
Your texts now arrive on another device. They open your email with "forgot my password", receive the code, and from the email everything else falls.

Notice where the weak point sits: not your password, not your phone, not even your data. It is the counter where a person decides whether the caller is you. Your security depends on the training of someone you have never met, serving a hundred customers a day.

That is why moving your second factor off SMS is the only defence that does not depend on that person.

What to do this week

None of this depends on the leak being confirmed.

Move your second factor off SMS. Email, bank, social accounts: wherever it is offered, use an authenticator app. It is the highest-value change per minute spent, and the only one that protects you if your number stops being yours.

Ask your carrier what it takes to move your number to a new SIM. If the answer is "a phone call", that is the problem. Ask whether they offer in-person verification or an extra passphrase.

Put a PIN on the SIM. It is in your phone's security menu, takes a minute, and blocks the simple case where someone steals the handset and pulls the card.

Change your mental rule about who calls you. Someone knowing your ID number proves nothing now. It was never good proof; today it is not even weak proof. If your bank calls, hang up and call the number on the card.

And never read a code out loud. No bank, no carrier and no app will ask you over the phone for the code that just arrived.

What this means for those of us who build software

If you build systems for Dominican customers, two assumptions changed.

First: ID numbers and phone numbers are not secrets. They never fully were, but any system verifying identity by asking for a national ID is performing theatre. If your account recovery rests on "tell me your document number", your account recovery is public.

Second: SMS OTP is a borrowed factor. You do not control it — the carrier does, and its security is the security of their customer service desk. If your app protects money or sensitive data, at least offer an authenticator app.

And a third, less comfortable one that applies even if this case turns out to be false: you are one export away too. Almost every customer database can be dumped whole from the inside. The useful questions are not about firewalls:

How many fields do you store that you never use? Each one is surface.
Who can export the full customer table, and is it logged?
If a dump with your schema appeared tomorrow, could you say within hours whether it is yours and how old it is?

That last one is what separates a credible response from two weeks of silence.

How to read the next leak claim

There will be another one. Better to have criteria beforehand than during.

Is there a verifiable sample? Not screenshots: records an independent party can cross-check against known real data. A screenshot proves nothing about origin; a thousand rows that line up does.

Are the fields internal or catalogue? A name and a phone number can come from anywhere. An ICCID, an internal code or a billing cycle do not appear on a public form. The fields that exist only inside the system are the hard part to fake.

Is the data fresh? The question that kills most claims. If not one line in the sample was activated this year, you are probably looking at old data from another breach, resold under a new label.

Has anyone cross-checked it against previous leaks? Repackaging old dumps and selling them as new is a business, not an exception. It is the most boring explanation and therefore the most common one.

And who is telling you? An account that aggregates leaks is not a source that verifies them. Amplifying and checking are two different jobs.

With those five filters, most internet scares resolve themselves within a day.

What a company should publish to end it

There is an asymmetry almost nobody notices: the company is the only party that can close this cheaply.

Whoever claims to hold the data cannot prove its origin without exposing themselves. Anyone reviewing from outside can only say "looks plausible". But the company has its own schema. It knows whether a field named the way the sample names it exists in its systems, whether that internal code format is theirs, and whether those activation dates match its own history.

A useful statement is three sentences:

We reviewed the sample, and these fields do or do not match our schema.
If they match, this is the scope and these are the affected accounts.
Here is what you should do, with concrete instructions.

A useless statement says customer security is a priority.

Silence carries a cost that is invisible at the time: it leaves everyone managing the worst case alone. And it keeps the rumour alive, which is harder to kill in two weeks than in two days.

The legal frame, and its gap

In the Dominican Republic the reference is Ley 172-13, of December 13, 2013, on the protection of personal data. What it clearly establishes:

Processing personal data requires the subject's prior, free, unambiguous and specific consent, save the exceptions the law itself sets out.
Whoever processes data must adopt technical and organisational measures to prevent unauthorised access or alteration.
You have the right to have your data rectified, updated or deleted, and the controller has a maximum of ten business days from your claim.

What I did not find in the sources I checked is an explicit obligation to notify a breach to those affected. If a later regulation creates one, I did not come across it, and that seems worth saying plainly instead of asserting the opposite.

That gap explains a lot. When no legal clock is running, "no comment" is a viable strategy. In Europe it would not be: the regulation there requires notification within 72 hours. Here the incentive points the other way.

How this probably ends

There are three possible endings. Someone verifies the samples and they turn out to be authentic. Someone shows they are old data, recombined from earlier leaks — which happens more than people think. Or nothing happens and the story fades in two weeks without anyone knowing.

The third is the most likely. And it is the worst, because it leaves everyone with the same doubt and no reason to change anything.

That is why the advice above does not depend on the ending. Moving your second factor off SMS is worth it if this turns out to be smoke, worth it if it turns out to be true, and worth it the next time a list with your name on it shows up.

Sources: N Digital · EyR · Ley 172-13, official text

I write up the things I break and fix at codewithgabo.com.

React 19.3, el compilador y un CVSS 10: lo que cambió mientras no mirabas

Gabriel Abreu — Wed, 16 Sep 2026 00:12:20 +0000

Esta semana saqué Create React App de un proyecto y dejé escrito el plan para sacarlo de otro. Los dos eran de 2022 y 2023, y los dos seguían funcionando. Eso es lo engañoso: seguir funcionando y seguir siendo la forma correcta de hacerlo son cosas distintas, y entre una y otra pasaron cuatro cambios grandes en React que no se enteran solos.

Ninguno es un rumor. Los cuatro están publicados en el blog oficial, con fecha.

1. El compilador ya borra tu `useMemo`

React Compiler llegó a la versión 1.0 el 7 de octubre de 2025. No es beta, no es experimento: memoriza automáticamente componentes y hooks, funciona en React y en React Native, y se instala con Babel, Vite o Rsbuild.

Lo que eso significa en la práctica es que la mayoría de tus useMemo y useCallback dejaron de ser trabajo tuyo. Los escribías para evitar renders; el compilador hace esa optimización en tiempo de compilación, sin reescribir nada.

Hay un detalle de instalación que se come a mucha gente: si tenías eslint-plugin-react-compiler, ya no va. Se elimina y se usa eslint-plugin-react-hooks@latest, porque las reglas del compilador ahora viajan dentro de sus presets recommended y recommended-latest.

El compilador se apoya en las Reglas de React. Si tu componente las rompe, el compilador lo detecta y se salta ese componente en lugar de optimizarlo mal. Por eso las advertencias del linter dejaron de ser cosmética: ahora determinan si tu código se optimiza o no.

2. Si sirves Server Components, ahora tienes calendario de parches

Este es el cambio que menos se comenta y más te puede costar.

El 3 de diciembre de 2025, React publicó una vulnerabilidad crítica en React Server Components: CVE-2025-55182, con CVSS 10.0, la puntuación máxima. Un atacante sin autenticar podía mandar una petición HTTP a cualquier endpoint de Server Function que, al deserializarse, lograba ejecución remota de código en el servidor.

Afectaba a react-server-dom-webpack, react-server-dom-parcel y react-server-dom-turbopack en las versiones 19.0, 19.1.0, 19.1.1 y 19.2.0. Se arregló en 19.0.1, 19.1.2 y 19.2.1.

Y la lista de frameworks afectados es la lista de lo que la gente usa: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc y rwsdk.

Ocho días después llegó la segunda tanda. El 11 de diciembre se publicaron dos más:

Denegación de servicio (CVE-2025-55184, CVE-2025-67779 y CVE-2026-23864, CVSS 7.5): peticiones maliciosas a endpoints de Server Function provocaban bucles infinitos que cuelgan el proceso, se comen el CPU y terminan en caídas o en falta de memoria.
Exposición de código fuente (CVE-2025-55183, CVSS 5.3): una petición podía devolver el código de tus Server Functions.

El detalle de esa última merece leerse con cuidado, porque decide si te afecta:

'use server';

export async function serverFunction(name) {
  const conn = db.createConnection('SECRET KEY'); // expuesto
  const user = await conn.createUser(name);
  return {
    id: user.id,
    message: `Hello, ${name}!` // expuesto
  }
}

Solo se exponen los secretos escritos a mano en el código. Los que vienen de process.env no. O sea: si alguna vez pegaste una llave directo en un archivo con 'use server' para probar, ese es el archivo.

Se arregló en 19.0.4, 19.1.5 y 19.2.4.

La conclusión operativa es sencilla y no es sobre React: si tu aplicación sirve Server Components, dejó de ser una dependencia que se actualiza cuando hay tiempo. Y si no usas RSC ni servidor, ninguna de estas te toca.

3. React 19.3 trajo cosas que antes se resolvían fuera de React

Salió el 9 de septiembre de 2026, hace días.

<ViewTransition> te deja animar elementos cuando entran, salen, se mueven o cambian de tamaño, usando la View Transition API del navegador:

import { ViewTransition } from 'react';

{isShowing && (
  <ViewTransition>
    <Component />
  </ViewTransition>
)}

React decide qué animación correr según cómo cambió el árbol: entrada, salida, actualización o compartida. Y si necesitas que la misma actualización de estado se anime distinto según por qué ocurrió, addTransitionType marca la causa:

function nextSlide() {
  startTransition(() => {
    addTransitionType('next');
    setCurrentSlide(c => c + 1);
  });
}

<ViewTransition
  enter={{
    'next': 'from-right',
    'previous': 'from-left',
  }}
  exit={{
    'next': 'to-left',
    'previous': 'to-right',
  }}
>
  <Page />
</ViewTransition>

Los refs en Fragment resuelven el problema de querer tocar el DOM de un grupo de elementos sin envolverlo en un div que no necesitabas:

<Fragment ref={fragmentRef}>
  {posts.map(post => (
    <Heading key={post.id}>{post.title}</Heading>
  ))}
</Fragment>

El FragmentInstance trae un conjunto acotado de métodos: addEventListener, removeEventListener, dispatchEvent, focus, focusLast, blur, observeUsing, unobserveUsing, getClientRects, getRootNode, compareDocumentPosition y scrollIntoView.

Ese observeUsing es el que a mí me importa: conectar un IntersectionObserver a una lista sin fabricar un contenedor solo para tener dónde agarrarse.

browser() le dice a un componente que no se renderice en el servidor:

import { use } from 'react';
import { browser } from 'react-dom';

function Component() {
  use(browser());
  // ...
}

Durante el renderizado en servidor se muestra el fallback del Suspense más cercano. Cuando el componente hidrata en el cliente, use(browser()) ya no suspende y todo sigue normal. Es la versión oficial del truco del useEffect con isClient que todos hemos escrito.

También llegó integración con Trusted Types, que ayuda contra XSS basado en DOM: React ahora pasa esos valores sin convertirlos a texto, para que el navegador pueda validarlos.

Y una que no se ve pero se siente: las transiciones ahora se renderizan de forma independiente en vez de enredarse en un solo render. Una transición lenta ya no retrasa a las otras.

4. React ya no depende solo de Meta

En octubre de 2025 se anunció la React Foundation, y el 24 de febrero de 2026 se publicó su nueva casa: la Linux Foundation.

Ocho miembros fundadores platino: Amazon, Callstack, Expo, Huawei, Meta, Microsoft, Software Mansion y Vercel. Una junta directiva con representantes de cada uno y Seth Webster como director ejecutivo.

Con una aclaración que conviene leer completa: la gobernanza técnica de React es independiente de la junta. La dirección técnica la siguen marcando quienes contribuyen y mantienen React, no los miembros de la fundación.

Para el que solo escribe componentes, esto no cambia nada mañana. Cambia el riesgo a cinco años, que es el que uno realmente asume cuando escoge un framework.

Qué hacer con todo esto

Si tuviera que ordenarlo por urgencia:

Si sirves Server Components, revisa tu versión hoy. Un CVSS 10.0 no se negocia.
Si escribes useMemo por reflejo, prueba el compilador. Y si tenías el plugin viejo de ESLint, quítalo.
Si tienes un proyecto en Create React App, React dejó de recomendarlo el 14 de febrero de 2025. Migrar toma menos de lo que parece.
Lo de 19.3 puede esperar, pero léelo: hay cosas ahí que estás resolviendo a mano ahora mismo.

Fuentes: React 19.3 · React Compiler v1.0 · Vulnerabilidad crítica en RSC · DoS y exposición de código en RSC · The React Foundation

I write up the things I break and fix at codewithgabo.com.

React 19.3, the Compiler, and a CVSS 10: What Changed While You Weren't Looking

Gabriel Abreu — Wed, 16 Sep 2026 00:11:44 +0000

This week I pulled Create React App out of one project and wrote the plan to pull it out of another. Both were from 2022 and 2023, and both still worked. That is the deceptive part: still working and still being the right way to do it are different things, and between the two, four large changes happened in React that do not announce themselves.

None of this is rumour. All four are on the official blog, with dates.

1. The compiler already deletes your `useMemo`

React Compiler reached 1.0 on October 7, 2025. Not beta, not an experiment: it automatically memoizes components and hooks, works in React and React Native, and installs through Babel, Vite or Rsbuild.

What that means in practice is that most of your useMemo and useCallback stopped being your job. You wrote them to avoid re-renders; the compiler does that optimization at build time, without rewriting anything.

There is one installation detail that catches people: if you had eslint-plugin-react-compiler, it is gone. You remove it and use eslint-plugin-react-hooks@latest, because the compiler's lint rules now ship inside its recommended and recommended-latest presets.

The compiler leans on the Rules of React. If a component breaks them, the compiler detects it and skips that component rather than optimizing it wrongly. Which means linter warnings stopped being cosmetic: they now decide whether your code gets optimized at all.

2. If you serve Server Components, you now have a patch calendar

This is the change that gets discussed least and can cost you most.

On December 3, 2025, React published a critical vulnerability in React Server Components: CVE-2025-55182, CVSS 10.0, the maximum score. An unauthenticated attacker could craft an HTTP request to any Server Function endpoint that, when deserialized by React, achieved remote code execution on the server.

It affected react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack in versions 19.0, 19.1.0, 19.1.1 and 19.2.0. Fixed in 19.0.1, 19.1.2 and 19.2.1.

And the list of affected frameworks is the list of what people actually use: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc and rwsdk.

Eight days later came the second batch. On December 11 two more were published:

Denial of service (CVE-2025-55184, CVE-2025-67779 and CVE-2026-23864, CVSS 7.5): malicious requests to Server Function endpoints caused infinite loops that hang the process, eat CPU, and end in crashes or out-of-memory.
Source code exposure (CVE-2025-55183, CVSS 5.3): a request could return the source of your Server Functions.

The detail in that last one is worth reading carefully, because it decides whether it touches you:

'use server';

export async function serverFunction(name) {
  const conn = db.createConnection('SECRET KEY'); // exposed
  const user = await conn.createUser(name);
  return {
    id: user.id,
    message: `Hello, ${name}!` // exposed
  }
}

Only secrets hardcoded in the source are exposed. Ones coming from process.env are not. So: if you ever pasted a key straight into a file with 'use server' to test something, that is the file.

Fixed in 19.0.4, 19.1.5 and 19.2.4.

The operational conclusion is simple and it isn't about React: if your app serves Server Components, it stopped being a dependency you update when there's time. And if you use neither RSC nor a server, none of these reach you.

3. React 19.3 shipped things that used to be solved outside React

It came out on September 9, 2026, days ago.

<ViewTransition> animates elements as they enter, exit, move or resize, using the browser's View Transition API:

import { ViewTransition } from 'react';

{isShowing && (
  <ViewTransition>
    <Component />
  </ViewTransition>
)}

React picks which animation to run based on how the tree changed: enter, exit, update or share. And when the same state update should animate differently depending on why it happened, addTransitionType marks the cause:

function nextSlide() {
  startTransition(() => {
    addTransitionType('next');
    setCurrentSlide(c => c + 1);
  });
}

<ViewTransition
  enter={{
    'next': 'from-right',
    'previous': 'from-left',
  }}
  exit={{
    'next': 'to-left',
    'previous': 'to-right',
  }}
>
  <Page />
</ViewTransition>

Fragment refs solve wanting to touch the DOM of a group of elements without wrapping it in a div you never needed:

<Fragment ref={fragmentRef}>
  {posts.map(post => (
    <Heading key={post.id}>{post.title}</Heading>
  ))}
</Fragment>

The FragmentInstance carries a deliberately small set of methods: addEventListener, removeEventListener, dispatchEvent, focus, focusLast, blur, observeUsing, unobserveUsing, getClientRects, getRootNode, compareDocumentPosition and scrollIntoView.

observeUsing is the one I care about: attaching an IntersectionObserver to a list without manufacturing a container just to have something to hold.

browser() tells a component not to render on the server:

import { use } from 'react';
import { browser } from 'react-dom';

function Component() {
  use(browser());
  // ...
}

During server rendering the nearest Suspense fallback shows. Once the component hydrates on the client, use(browser()) no longer suspends and rendering continues normally. It is the official version of the useEffect plus isClient trick everyone has written.

Trusted Types integration also landed, which helps against DOM-based XSS: React now passes those values through without coercing them to strings, so the browser can validate them.

And one you don't see but feel: transitions now render independently instead of being entangled into a single render. A slow transition no longer holds up unrelated ones.

4. React no longer depends on Meta alone

The React Foundation was announced in October 2025, and on February 24, 2026 its new home was published: the Linux Foundation.

Eight platinum founding members: Amazon, Callstack, Expo, Huawei, Meta, Microsoft, Software Mansion and Vercel. A board with a representative from each, and Seth Webster as executive director.

With a clarification worth reading in full: React's technical governance is independent from that board. Technical direction is still set by the people who contribute to and maintain React, not by the foundation's members.

If you only write components, this changes nothing tomorrow. It changes the five-year risk, which is the one you actually take on when you pick a framework.

What to do with all of this

If I had to order it by urgency:

If you serve Server Components, check your version today. A CVSS 10.0 is not a negotiation.
If you write useMemo by reflex, try the compiler. And if you had the old ESLint plugin, remove it.
If you have a project on Create React App, React stopped recommending it on February 14, 2025. Migrating takes less than it looks.
19.3 can wait, but read it: there are things in there you are solving by hand right now.

Sources: React 19.3 · React Compiler v1.0 · Critical vulnerability in RSC · DoS and source code exposure in RSC · The React Foundation

I write up the things I break and fix at codewithgabo.com.