u/codebymelendez

La IA escribe mejor código. Pero no escribe código más seguro.

En 2026, Veracode encontró algo incómodo:
la tasa de aprobación en pruebas de seguridad sigue clavada en 55%, mientras los benchmarks de capacidad de codificación siguen subiendo.

¿Cómo se traduce esto a lenguaje de negocio?
la IA mejora la velocidad y la calidad funcional del código… Pero no está cerrando la brecha de seguridad.

En el artículo cuento con evidencia concreta:

• Por qué “compila y funciona” es diferente a “está listo para producción”.
• Qué cuatro riesgos se repiten una y otra vez (controles de acceso, secretos, dependencias alucinadas, inyección).
• Qué pipeline mínimo necesita un equipo antes de dejar que el vibe coding toque datos reales.

No es un rant anti-IA.
Es un mapa práctico:
qué dejamos de hacer cuando la IA nos dio velocidad gratis, y cómo recuperar la parte de verificación que perdimos.

En casi todas las demos de software médico que he visto en Venezuela aparece la palabra “inteligencia artificial”. Pero cuando preguntas qué datos necesitan esos modelos, cómo se validarían en tu hospital o quién responde clínicamente por un falso negativo, la conversación se queda muy corta.

Revisando la evidencia publicada y lo que he visto en proyectos reales, llegué a una conclusión simple: en salud, el cuello de botella no es el algoritmo, son los datos y la institución que lo va a usar.

Algunos datos concretos:

• ~76% de los dispositivos médicos con IA autorizados por la FDA son de radiología. La “IA clínica” aprobada es, en la práctica, IA de imágenes (nódulos, triaje, reconstrucción), no sistemas que “gestionan” el hospital.
• El Epic Sepsis Model, implementado en cientos de hospitales de EEUU, tuvo una AUROC de 0,63 y un valor predictivo positivo de 12% en la validación externa de 2021 (muchos falsos positivos y sepsis que no detectaba).
• En la versión nueva (ESM v2), un estudio prospectivo multicéntrico con 227k encuentros reporta AUROC 0,82–0,92 pero VPP sólo 0,13–0,26, con rendimiento distinto en cada hospital y necesidad explícita de validación local.

Con esa foto en mente, me puse a escribir una guía aterrizada para clínicas venezolanas:

• Qué tipo de IA médica está realmente aprobada hoy.
• Por qué el mismo modelo funciona en un hospital y falla en otro.
• Las seis capas que una institución tiene que resolver antes de pensar en IA clínica (datos estructurados, histórico, interoperabilidad, infraestructura, gobernanza, validación local).
• Qué sí funciona hoy en una clínica venezolana: automatización determinista e IA administrativa con supervisión humana.
• Cinco preguntas que separan una propuesta de IA seria de una presentación comercial.

Si trabajas en salud, TI hospitalaria o estás montando producto HealthTech para la región, te puede interesar leerla y discutir:

Inteligencia artificial en hospitales de Venezuela: qué funciona hoy y qué todavía no.

Me interesa especialmente feedback de gente que esté en hospitales (clínicos, TI, proveedores) y de quienes hayan intentado meter IA en entornos con historias clínicas en papel o sistemas que no se hablan entre sí.

Acabo de publicar un artículo largo sobre desarrollo agéntico y lo que realmente significa para los equipos de software.

Mi idea principal es esta: los agentes de IA no hacen que un equipo sea mejor por arte de magia. Amplifican el sistema en el que se usan.

Si tu repo tiene tests débiles, CI inestable, límites poco claros o capacidad de revisión limitada, los agentes van a generar más ruido que valor. Pero si tu base de ingeniería está bien montada, sí pueden ayudar mucho con tareas repetitivas, scaffolding, refactors y cobertura de tests.

También incluí un ejemplo pequeño en Next.js con un ciclo agéntico controlado, salida tipada, validación de herramientas y un presupuesto fijo de pasos. No quería hacer una demo “llamativa”, sino mostrar cómo se ve realmente un patrón seguro para producción.

Mi conclusión: antes de adoptar agentes, arregla primero el verificador.

Me interesa saber cómo lo están viendo otros: ¿ya están usando flujos agénticos en producción o todavía los prueban solo en tareas aisladas?

Casi todos los ejemplos de “Kafka en salud” que se ven por ahí son teóricos o centrados en EHR de EEUU/Europa. Quería compartir un caso concreto de un hospital mediano en Venezuela donde usamos Kafka como columna vertebral de eventos entre el HIS, el LIS y el sistema de facturación.

Contexto:

• Entre 4 y 8 sistemas necesitaban enterarse de lo mismo en tiempo (casi) real: admisiones, resultados de laboratorio, cargos.
• Las integraciones punto a punto ya eran inmanejables: scripts ad hoc, datos duplicados, errores difíciles de auditar.
• El hospital sabía que en los próximos años iba a añadir más sistemas (BI, SAP, nuevos módulos clínicos).

Qué terminamos haciendo:

• Definir topics por dominio clínico (admisiones, resultados-laboratorio, ordenes-medicas, facturacion-eventos) en vez de “un topic para todo”.
• Particionar por paciente o por episodio de atención para mantener el orden de los eventos clínicos por caso.
• Configurar replication factor 3 y min.insync.replicas=2, porque perder un resultado de laboratorio no es solo “dato de negocio”.
• Activar productores idempotentes y transaccionales (exactly-once semantics) para resultados de laboratorio y eventos de facturación, donde los duplicados son peligrosos.

En el artículo explico con más detalle:

• Cómo mapeamos mensajes HL7/FHIR a topics de Kafka.
• Los trade‑offs de costo de infraestructura vs. resiliencia en contexto hospitalario.
• Cuándo Kafka es claramente la herramienta equivocada (clínicas pequeñas con pocos sistemas y bajo volumen de eventos).

I started getting much better results from Claude Code when I stopped dropping it into problems with almost no context.

Now, before I ask for anything, I spend 30–60 seconds giving it the shape of the task:

• what the project is trying to do,
• what I’m optimizing for,
• what I already tried,
• and any constraints that matter.

It sounds simple, but it changed the output more than I expected. I get fewer generic suggestions, less back-and-forth, and more answers that fit the actual codebase instead of a hypothetical one. The biggest difference for me was not “better prompts” in the abstract, but giving enough context so Claude could make useful tradeoffs instead of guessing. Curious what small workflow change made Claude Code more useful for you.

What’s one habit that actually changed your day-to-day results?

Anthropic acaba de lanzar Claude Fable 5, su modelo más capaz hasta ahora para programación, trabajo de oficina, visión e investigación.
Lo que me importa no es solo que es “más inteligente”, sino qué cambia en el día a día de un dev o freelancer en LATAM.

Cosas que considero pueden hacer más fácil el trabajo:

• Prototipar SaaS y MVPs mucho más rápido.
• Refactor y mantenimiento de bases de código grandes sin perder la cabeza.
• Automatizar soporte, documentación y QA.
• Leer screenshots, flujos e interfaces para debug o para generar código.
• Ayuda para contenido técnico, SEO y workflows con IA.

En nuestro contexto, donde el tiempo, el talento y la velocidad de ejecución son clave, este modelo puede ser una ventaja real. Creo que nuestro país tiene muchas áreas que necesitan de ideas, trabajo duro, reconstrucción y modernización. La tecnología y la IA, usadas bien, pueden ser parte de ese cambio.
Estoy recolectando ideas y ejemplos prácticos de uso para builders hispanos; si quieres profundizar, lo dejo en mi web: codebymelendez

¿Qué usos le ven ustedes para proyectos hechos desde Venezuela o LATAM?

Hola a todos. Soy Ramón, Ingeniero Informático venezolano. Llevo meses escribiendo guías técnicas sobre cosas que me voy encontrando al trabajar con clínicas y empresas venezolanas, y que casi no tienen documentación en español orientada a nuestra realidad.

Lo que he publicado hasta ahora:

Qué es un HIS (Sistema de Gestión Hospitalaria) y por qué casi siempre falla al implementarse en Venezuela

Historia clínica electrónica en Venezuela: qué es, cómo funciona y qué sistemas existen en 2026

Telemedicina en Venezuela: guía técnica para clínicas privadas

Interoperabilidad en salud: HL7 FHIR, niveles HIMSS y por qué fracasan los proyectos (el más reciente)

Todo está aquí: https://codebymelendez.com/insights

No es un blog de marketing, es donde voy documentando lo que implemento en proyectos reales (arquitecturas, errores, decisiones técnicas, etc.).

Si trabajan en salud, logística o automatización en Venezuela y tienen preguntas técnicas concretas, con gusto respondo en los comentarios y, si hace falta, hasta puedo escribir una guía específica sobre el tema.

Trabajé en una red hospitalaria donde un médico en urgencias podía tardar entre 3 y 8 minutos en encontrar un resultado de laboratorio.

No era porque el sistema fuera lento. Era porque había como 10 sistemas distintos que nunca fueron diseñados para hablar entre sí: admisión, laboratorio, radiología, farmacia, historia clínica… Cada uno comprado en momentos diferentes, cada uno con su propio formato, y peor aún, cada uno identificando al mismo paciente con un código distinto.

Recuerdo que el flujo era algo así:
sales de un sistema → entras a otro → pruebas con otro identificador → esperas → repites.

Mientras tanto, el paciente esperando.

Y muchas veces, decisiones clínicas tomándose con información incompleta.

Lo más complicado del proyecto ni siquiera fue técnico. Era algo organizacional.

Convencer a equipos que llevaban años manteniendo “su” sistema de que integrarlo no era una amenaza. Había mucho sentido de propiedad. Cada sistema era su territorio. Eso tomó más reuniones y más paciencia que cualquier problema de arquitectura.

Y luego viene el problema que nadie te advierte:

los datos.

El cliente siempre cree que están “más o menos bien”.

Pero realmente no lo están.

Casi el 40% del tiempo se fue en limpieza y mapeo, no en desarrollo: pacientes duplicados, resultados sin médico asociado, timestamps inconsistentes entre sistemas que supuestamente estaban sincronizados…

Aprendizaje clave: datos limpios primero, velocidad después.

Me da curiosidad saber cómo está esto hoy.

¿Alguien aquí ha trabajado con sistemas de salud en Venezuela recientemente?
¿Cómo están manejando la gestión de información clínica en clínicas privadas?

Trabajé en una red hospitalaria donde un médico en urgencias podía tardar entre 3 y 8 minutos en encontrar un resultado de laboratorio.

No era porque el sistema fuera lento. Era porque había como 10 sistemas distintos que nunca fueron diseñados para hablar entre sí: admisión, laboratorio, radiología, farmacia, historia clínica… Cada uno comprado en momentos diferentes, cada uno con su propio formato, y peor aún, cada uno identificando al mismo paciente con un código distinto.

Recuerdo que el flujo era algo así:
sales de un sistema → entras a otro → pruebas con otro identificador → esperas → repites.

Mientras tanto, el paciente esperando.

Y muchas veces, decisiones clínicas tomándose con información incompleta.

Lo más complicado del proyecto ni siquiera fue técnico. Era algo organizacional.

Convencer a equipos que llevaban años manteniendo “su” sistema de que integrarlo no era una amenaza. Había mucho sentido de propiedad. Cada sistema era su territorio. Eso tomó más reuniones y más paciencia que cualquier problema de arquitectura.

Y luego viene el problema que nadie te advierte:

los datos.

El cliente siempre cree que están “más o menos bien”.

Pero realmente no lo están.

Casi el 40% del tiempo se fue en limpieza y mapeo, no en desarrollo: pacientes duplicados, resultados sin médico asociado, timestamps inconsistentes entre sistemas que supuestamente estaban sincronizados…

Aprendizaje clave: datos limpios primero, velocidad después.

Me da curiosidad saber cómo está esto hoy.

¿Alguien aquí ha trabajado con sistemas de salud en Venezuela recientemente?
¿Cómo están manejando la gestión de información clínica en clínicas privadas?

Estoy escribiendo sobre Salud Digital aplicada al contexto venezolano y me parece que la mayoría del contenido que hay online parte de supuestos irreales: buena conexión, pacientes con apps instaladas, clínicas con infraestructura estable y poco problema de integración.

Mi tesis es otra: la telemedicina solo tiene sentido si resuelve un flujo clínico real y se integra con historia clínica electrónica y gestión hospitalaria. Si no, termina siendo una videollamada más.

En el caso venezolano, creo que lo más sensato es pensar en este orden:

1. Canal operativo simple para coordinación y recordatorios.
2. Videoconsulta ligera, sin fricción para el paciente.
3. Integración con la historia clínica.
4. Interoperabilidad con el resto del sistema.

También creo que Zoom y Teams no deberían ser la base de una estrategia clínica, aunque sí sirvan para reuniones internas.

Telemedicina en Venezuela

¿Qué están viendo ustedes en la práctica?

Muchas veces hablamos de buenas prácticas (cloud, microservicios, alta disponibilidad), pero cuando trabajas en entornos donde la infraestructura no es fiable, varias de esas decisiones dejan de tener sentido.

Algunas cosas que he visto y que cambian completamente cómo debes diseñar sistemas:

1. Offline-first no es opcional
Si dependes de conexión constante, tu sistema va a fallar.
Hay que diseñar pensando en:

• almacenamiento local
• colas de sincronización
• resolución de conflictos

2. La consistencia perfecta es un lujo
En estos contextos, muchas veces toca aceptar:

• eventual consistency
• datos temporales incompletos
• reconciliación posterior

3. Cortes eléctricos ≠ solo downtime
También implican:

• operaciones a medias
• posible corrupción de datos
• pérdida de estado

Si no manejas bien transacciones, el sistema se rompe silenciosamente.

4. UX simple > arquitectura elegante
El usuario no va a adaptarse al sistema.
Si el flujo es complicado, simplemente no lo usan (y vuelven al papel).

5. Implementación por fases
Intentar desplegar todo de una vez casi siempre falla.
Empezar por módulos críticos cambia totalmente el resultado.

Me interesa saber si alguien aquí ha tenido que diseñar o mantener sistemas en condiciones similares:

• ¿Cómo manejan offline + sync?
• ¿Qué patrones les han funcionado?
• ¿Algún fallo que les haya enseñado algo importante?

Saludos

En muchas conversaciones sobre “modernizar” el sistema de salud en Venezuela, se menciona implementar un sistema de gestión hospitalaria (HIS)… pero rara vez se explica bien qué es eso en la práctica.

Un HIS no es simplemente “un software”.

Es el sistema que conecta todo dentro de una clínica u hospital:

• Admisión de pacientes
• Citas médicas
• Historias clínicas
• Laboratorio
• Farmacia
• Facturación

En teoría, suena perfecto.
En la práctica, es donde empiezan los problemas.

Por lo que he visto, los fallos más comunes en Venezuela no son tecnológicos, sino de enfoque:

• Se intenta implementar todo de golpe
• No hay infraestructura estable (electricidad, red, servidores)
• Falta personal técnico que mantenga el sistema
• No se adapta el sistema a la realidad operativa del centro

Y algo que casi nunca se menciona:

👉 Un HIS mal implementado puede empeorar el caos en lugar de solucionarlo.

Por eso, creo que el enfoque debería ser distinto:

• Empezar por procesos críticos (admisión, historias clínicas básicas)
• Implementar por fases, no como un “proyecto gigante”
• Usar soluciones que puedan funcionar con conectividad limitada
• Asegurar soporte técnico desde el inicio

Me interesa mucho saber cómo lo están viendo ustedes en la práctica:

• ¿Alguien aquí ha trabajado con sistemas digitales en clínicas u hospitales en Venezuela?
• ¿Qué herramientas se están usando realmente hoy?
• ¿Qué ha funcionado y qué ha sido un desastre?

Creo que este tema se habla mucho desde la teoría, pero poco desde lo que realmente pasa en el día a día.