AiLabAiLab
AiLab Evolving
Marco teórico y práctico para construir software con IA · Edición noviembre 2026

Tú decides qué construir.
La IA lo construye y lo prueba.

Sitio de divulgación para estudiantes y profesionales de Ingeniería en Computación e Informática. Hace unos meses proponíamos que el Tech Lead revisara cada línea que escribía el agente. Hoy eso ya no alcanza: la IA genera demasiado código, demasiado rápido. En su lugar, el agente escribe las pruebas, levanta el entorno y se pone a prueba a sí mismo — y tú te vuelves un profesional navaja suiza que sabe qué pedir, qué exigir como evidencia y cómo levantar la solución completa.

Acceso libre · Contenido bajo licencia abierta · Iniciativa sin fines de lucro

Filosofía

Tech Lead, Coding Agent y la evidencia entre los dos

La inteligencia artificial no reemplaza al ingeniero — lo convierte en un equipo entero. Lo que cambió en pocos meses es dónde pone la confianza ese ingeniero. Antes, en su propia lectura del código. Hoy, en un conjunto de pruebas documentadas que el agente genera y ejecuta. Cuatro pilares articulan esta relación.

El Tech Lead decide

Quien lleva la dirección del sistema sigue siendo una persona. Pero su trabajo cambió: ya no es el revisor de cada cambio — es quien define qué se construye, qué significa que funcione y qué evidencia exige antes de confiar.

  • Decide arquitectura, stack, dónde vive el producto y qué servicios se contratan.
  • Define los criterios de aceptación: qué tiene que pasar para que algo esté «listo».
  • Exige evidencia (pruebas, simulaciones, registros), no promesas ni diffs.
  • Conversa con el cliente o usuario final y traduce su realidad a requerimientos.

El Coding Agent construye

El agente cambia de sombrero según lo que dirijas: ingeniero de datos, frontend, DevOps. Lee archivos, escribe código, ejecuta comandos. Y produce mucho más de lo que una persona alcanza a leer con atención.

  • Materializa especificaciones en código, esquemas de datos y documentación.
  • Propone alternativas con sus pros y contras antes de elegir camino.
  • Opera dentro de límites explícitos: permisos, entornos aislados, nada destructivo sin aprobación.
  • No decide arquitectura ni desviaciones de los estándares sin aprobación.

El Coding Agent se pone a prueba

Esta es la pieza nueva del marco. El mismo agente que escribe el código escribe las pruebas, levanta el entorno (contenedores, bases de datos de prueba, emuladores) y corre todo hasta que la evidencia respalde el cambio.

  • Pruebas unitarias e integración generadas junto al código, no después.
  • Entornos simulados: Docker, bases de datos clonadas, dispositivos Android virtuales.
  • Pruebas de extremo a extremo que operan la interfaz como un usuario real.
  • Un informe de evidencia por cambio: qué se probó, cómo, y qué quedó fuera.

El Coding Agent también explica

Cuando el Tech Lead enfrenta una parte del sistema que no domina, el agente cumple un segundo rol: tutor técnico síncrono. La conversación misma sigue siendo una herramienta de descubrimiento.

  • Traduce conceptos técnicos a un lenguaje accesible.
  • Interpreta salidas crudas de comandos y advierte de riesgos no obvios.
  • Explica qué cubre una prueba y qué no — para que la evidencia se entienda.
  • Convierte cada tarea en aprendizaje real para el Tech Lead.

Lo que proponíamos en mayo de 2026

«El Tech Lead revisa cada cambio antes del merge»

Era razonable cuando el agente producía unas decenas de líneas por sesión. Dejó de serlo cuando empezó a producir módulos completos en una tarde. Revisar línea por línea pasó de ser un control de calidad a ser el cuello de botella del proyecto — y, peor, un control que ya no encuentra lo que busca: los errores sutiles de un sistema grande no se ven leyendo un diff. Lo documentamos con honestidad porque el marco es un documento vivo: cambia cuando la realidad cambia.

Lo que proponemos hoy

«El agente prueba lo que construye; el Tech Lead revisa la evidencia»

El agente escribe pruebas unitarias y de integración junto al código, levanta el entorno real o uno simulado (contenedores, bases clonadas, un teléfono Android virtual que él mismo opera) y ejecuta todo hasta que la evidencia respalda el cambio. El humano queda, sí, a merced de lo que hace la IA — pero con un conjunto de pruebas documentadas que avalan su desempeño, y con la red de seguridad de snapshots y respaldos que convierten cualquier error en un incidente de minutos.

El patrón diálogo cognitivo sigue vigente

Dejar de revisar cada línea no significa dejar de entender. Cada vez que el Tech Lead enfrenta una salida que no entiende, un informe de pruebas que le parece demasiado bueno o un comando cuya consecuencia no es obvia, tiene una elección: aceptarlo a ciegas o detenerse a preguntar qué significa. Detenerse, en esta metodología, no es perder velocidad — es ganar criterio. Y un resultado demasiado bueno para ser cierto suele ser un error de medición, no un logro.

La diferencia es la escala a la que se pregunta. Antes se preguntaba por una línea; hoy se pregunta por una prueba: ¿qué cubre? ¿qué deja fuera? ¿contra qué datos corrió? ¿se saltó en silencio? En los casos que documentamos, los hallazgos críticos siguen apareciendo porque alguien preguntó algo que parecía obvio.

“Una prueba que no corrió no es evidencia. Un número demasiado bueno es un bug. Y un servidor sin snapshot es una apuesta.”
Sé tu propio equipo

Un producto serio pide nueve especialistas. Hoy los encarnas tú.

Construir un producto de software profesional normalmente exige un equipo: arquitecto, ingeniero de datos, frontend, backend, DevOps, QA, seguridad, documentación, diseño. Contratarlo cuesta meses y un presupuesto que casi nadie tiene cuando recién empieza. Dirigiendo un Coding Agent, una sola persona cambia de sombrero y opera desde cada rol. No porque seas experta en los nueve — sino porque diriges al agente desde cada uno y, en el camino, aprendes de todos.

Arquitecto de software

Diseño de sistemas

Defines cómo se organiza el sistema en capas, qué patrones se usan y dónde están los límites. El agente propone estructuras; tú decides cuál aguanta el negocio real y por qué.

Ingeniero de datos

Modelo de datos

Describes las entidades y relaciones en prosa; el agente materializa el esquema; tú lo verificas gráficamente. Corregir un error de modelado pasó de tomar días a tomar minutos.

Desarrollador frontend

Interfaz y experiencia

Diriges la construcción de la interfaz: componentes, estados, responsividad, accesibilidad. El agente escribe el JSX y el CSS; tú juzgas si de verdad se entiende y se usa bien.

Desarrollador backend

Lógica y APIs

Coordinas la lógica de negocio, las APIs, las integraciones y las reglas que sostienen el producto. El agente conecta las piezas; tú garantizas que el contrato entre ellas sea correcto.

DevOps / SRE

Despliegue y operación

Llevas el producto a producción: entornos escalonados, CI/CD, monitoreo de uptime, respaldos. El agente escribe los scripts; tú decides cuándo y cómo se despliega — nunca un viernes.

QA / Tester

Calidad

Defines qué significa que algo «funcione». El agente escribe las pruebas, levanta el entorno y se depura contra ellas; tú aportas los casos límite que vienen del negocio y revisas la evidencia — no el código.

Especialista en seguridad

Hardening

Impones seguridad por diseño: autenticación, puertos cerrados, TLS, firewalls, respaldos cifrados, snapshots antes de cada cambio. El agente audita; tú firmas el checklist antes de que algo toque producción.

Technical writer

Documentación

La documentación deja de ser deuda: se genera junto al código. El agente redacta el README, los ADRs y la bitácora; tú aseguras que reflejen lo que de verdad decidiste y por qué.

Diseñador UX/UI

Identidad y flujos

Diriges la jerarquía visual, la identidad de marca y los flujos de uso. El agente arma el sistema de componentes; tú validas que la experiencia sea clara para quien no escribió el código.

El que coordina los nueve sombreros tiene un nombre: god stack developer

No es el que sabe todo de memoria. Es quien sabe dirigir cada disciplina con criterio, preguntar lo que no domina y exigir la evidencia de lo que el agente entrega. Cada proyecto que terminas suma horas reales de práctica en cada uno de esos roles. La formación académica entrega las bases y el marco conceptual; construir proyectos completos las consolida y les da contexto. Las dos se potencian: el aula explica el porqué, y el proyecto muestra el cómo y el cuándo.

Un detalle honesto: el décimo sombrero — el de Product Manager, que conversa con el cliente, prioriza y define el «para quién» — no se delega al agente. Ese siempre lo llevas tú. Es el que convierte capacidad técnica en un producto que a alguien le sirve.

Metodología

Un marco ágil para cuando la IA construye y prueba

Cuando la construcción se acelera varias veces gracias al agente, el cuello de botella deja de ser escribir código. Durante unos meses creímos que pasaba a ser revisar código. Hoy sabemos que tampoco: el cuello de botella es definir qué significa que algo funcione y exigir la evidencia de que funciona. La propuesta reorganiza prácticas ágiles conocidas alrededor de ese eje.

El marco se llama PACTO: el trato que hacemos con la IA cuando dejamos de leer cada línea. Cinco compromisos, uno por letra: Pruebas automatizadas que el agente escribe y ejecuta junto al código; Ambientes simulados donde corren (contenedores, bases clonadas, dispositivos virtuales); Contención para cuando algo igual falle (snapshots, respaldos verificados, sandbox, simulacros); Trazabilidad, un informe de evidencia por cambio que dice qué se probó y qué quedó fuera; y Oficio, el criterio del humano que define qué significa funcionar y exige esa evidencia. Hasta octubre de 2026 el marco se llamaba OBRA (Operación Bajo Revisión Activa); el nombre nuevo refleja que la revisión ya no es del código sino de la evidencia.

Qué cambia en la práctica

1 · El agente escribe las pruebas

Unitarias, de integración y de extremo a extremo, junto al código y no después. Incluye los casos raros: entradas malformadas, fechas en otra zona horaria, dos usuarios tocando lo mismo. El Tech Lead aporta los casos límite que vienen del negocio; el agente aporta los que vienen del oficio.

2 · El agente levanta el entorno

Contenedores con la base de datos real clonada, un servidor de prueba levantado desde el mismo snapshot que producción, o un dispositivo Android virtual que el agente instala, opera y observa. Las pruebas corren donde el producto va a vivir, no donde es cómodo.

3 · El humano revisa la evidencia

Un informe por cambio: qué se probó, contra qué datos, qué se saltó y por qué. El Tech Lead lo lee con la misma desconfianza sana de siempre — y cuando un resultado es demasiado bueno, lo contrasta con un caso conocido antes de celebrarlo.

Los contras, dichos sin rodeos. Quedas a merced de lo que hace la inteligencia artificial. Si las pruebas que escribió tienen el mismo punto ciego que el código, nadie lo verá hasta producción. Por eso el marco no se sostiene solo en las pruebas: se sostiene en la red de seguridad que las rodea — snapshots antes de cada cambio, respaldos cifrados fuera del servidor y simulacros que demuestran que esa red aguanta. Con eso, un error deja de ser una catástrofe y pasa a ser un incidente de minutos.

Manifiesto

Valoramos

  1. 1Evidencia de pruebas sobre lectura humana del código.
  2. 2Modelo de datos verificado sobre funcionalidad aparente.
  3. 3Entornos simulados y clonados sobre «probarlo en producción».
  4. 4Snapshots y respaldos verificados sobre confianza en que nada fallará.
  5. 5Ciclos cortos con quien usa el sistema sobre planes detallados a meses.
  6. 6Aprendizaje del Tech Lead sobre dependencia ciega del agente.

Es decir: aunque valoramos lo de la derecha (leer el código, la funcionalidad aparente, la confianza, los planes detallados), valoramos más lo de la izquierda.

Ciclo de vida — proyecto mediano (~6 semanas)

Un proyecto mediano —del tamaño que un equipo pequeño resolvería en unos pocos meses— cabe en alrededor de seis semanas bajo PACTO. La compresión viene de que el agente ejecuta y verifica a alta velocidad lo que antes se escribía y se revisaba a mano. Las decisiones siguen siendo humanas y secuenciales, y por eso el calendario se acorta sin desaparecer.

Semana 1

Descubrimiento

Conversaciones estructuradas con quien tiene el problema. El Tech Lead levanta dolores reales, glosario del dominio, actores y criterios de éxito a 90 días — apoyándose en el Coding Agent para estructurar preguntas, sintetizar respuestas y ponderar las problemáticas. Sin código todavía.

Aquí también se evalúa la viabilidad: qué servicios de terceros hacen falta (pasarela de pago, facturación electrónica, mensajería), qué requisitos exigen y cuánto cuestan al mes. Un proyecto que no cierra en números se detiene en esta semana, no en la sexta.

Semana 2

Modelado y criterios

El Tech Lead describe el modelo de datos por escrito; el Coding Agent lo materializa; el Tech Lead lo verifica gráficamente antes de avanzar. Y se escribe, en prosa, qué significa que cada módulo «funcione»: esos criterios serán las pruebas.

También se define la arquitectura por capas, la matriz de roles y datos sensibles, la política de autenticación y el plan de despliegue (entornos escalonados, dominios, certificados, puertos). Y se toma el primer snapshot del servidor antes de tocarlo.

Semanas 3–5

Construcción con evidencia

Sprints muy cortos (3 días hábiles). Cada cambio llega con sus pruebas generadas y ejecutadas por el agente, en un entorno real o simulado. El Tech Lead no lee el diff: lee el informe de evidencia y pregunta lo que no cuadra.

El agente asume el peso de la implementación y de la verificación: pruebas unitarias, de integración contra una base clonada, de extremo a extremo operando la interfaz. Lo que no tiene evidencia no se integra. Lo que tiene evidencia que no se entiende, tampoco.

Días 1-3 de S6

Validación + endurecimiento

Pruebas con personas externas al equipo, despliegue a un entorno de validación, revisión de seguridad automatizada y respaldos verificados antes de tocar producción.

Una checklist firmada de hardening es obligatoria: cierre de puertos no esenciales, certificados válidos, firewalls activos, respaldos cifrados con copia fuera del propio servidor y un simulacro de restauración que haya pasado.

Días 4-6 de S6 · mín. 3 días

Despliegue a producción

Salida a producción gradual, con al menos 3 días de margen y un snapshot tomado antes de empezar. Día 1: despliegue técnico y monitoreo intensivo. Día 2: validación con tráfico real. Día 3: ajustes, capacitación al cliente y traspaso a operación.

Producción nunca se hace en un solo día. Reglas básicas: no se despliega un viernes, el Coding Agent siempre necesita un Tech Lead despierto del otro lado, nada destructivo va dentro de un bloque que se pueda ejecutar sin leer, y todo comando que solo deba correr en un servidor comprueba él mismo en qué servidor está.

Continuo

Operación y simulacros

Canal de soporte abierto, respaldos validados periódicamente, observabilidad encendida — y un simulacro de desastre con cadencia fija: se clona el servidor desde un snapshot, se rompe a propósito y se mide cuánto tarda en volver.

El simulacro prueba lo que el respaldo diario no puede: que el archivo se descifra con la frase de hoy, que se restaura sin errores con los roles de hoy, y que nadie tiene que improvisar a las tres de la mañana. Todo termina sincronizado con el backlog.

Anti-patrones — qué no hacer

Listas de cosas correctas hay muchas; el aprendizaje real suele venir de entender qué rompe la metodología en cada paso. Varios de estos los aprendimos pagando.

  1. 1Revisar línea por línea lo que generó el agente — y creer que así se encuentran los errores.
  2. 2Aceptar «todas las pruebas pasan» sin preguntar cuántas se saltaron en silencio.
  3. 3Pruebas que siembran sus propios datos y coinciden consigo mismas: no ven el error real.
  4. 4Celebrar un número demasiado bueno en vez de contrastarlo con un caso conocido.
  5. 5«La seguridad la sumamos después» — nunca llega.
  6. 6Tocar un servidor de producción sin un snapshot de hace menos de una hora.
  7. 7Un respaldo que nunca se restauró es una esperanza, no un respaldo.
  8. 8Pegar en producción un comando destructivo copiado «para explicar».
  9. 9No llevar bitácora — sin registro, no hay aprendizaje y la metodología deja de evolucionar.
Capas instrumentales

Siete capas que sostienen la práctica

La metodología necesita instrumentos. Lo que importa es que cada capa esté presente y cumpla su rol — los productos concretos son intercambiables. Por cada capa damos una descripción, qué cubre y ejemplos de herramientas que cumplen ese rol hoy. Elige los que mejor se ajusten a tu contexto, presupuesto y restricciones.

Conocimiento y dirección

El cerebro del proyecto

Donde vive el contexto del proyecto: brief de visión, glosario del dominio, decisiones de arquitectura, actas de cliente, bitácora del Tech Lead y backlog priorizado.

  • Backlog priorizado y trazable.
  • Decisiones registradas como artefactos numerados (ADRs).
  • Plantillas reutilizables (preguntas al cliente, checklists).
  • Bitácora del Tech Lead como hilo de aprendizaje.

Ejemplos hoy

NotionConfluenceObsidianOutline

Versionado y respaldo

La memoria inmutable

Sistema de control de versiones distribuido para registrar cada cambio, separar entornos por ramas y poder volver atrás cuando algo se rompe.

  • Ramas separadas para producción, validación y desarrollo.
  • Cada cambio llega con sus pruebas: sin evidencia no se integra.
  • Integración continua que corre la suite completa y bloquea el merge si falla.
  • Diagramas y documentación versionados con el código.

Ejemplos hoy

GitHubGitLabBitbucketGitea

Coding Agent

La capacidad de ejecución

Asistente de desarrollo dirigido por instrucciones — escribe código, refactoriza, propone alternativas, y escribe y ejecuta las pruebas que respaldan cada cambio, dentro de los límites que el Tech Lead define.

  • Generación de scaffolding y funcionalidades específicas.
  • Pruebas escritas y ejecutadas junto al código, con informe de evidencia.
  • Revisión automatizada de seguridad sobre cada cambio.
  • Permisos y sandbox: nada destructivo sin aprobación explícita.

Ejemplos hoy

ClaudeClaude CodeCursorCodex

Banco de pruebas

Entornos simulados y clonados

Donde el agente se pone a prueba a sí mismo: contenedores desechables con la base de datos clonada, un servidor levantado desde el mismo snapshot que producción, un navegador o un dispositivo Android virtual que el agente opera como lo haría un usuario.

  • Base de datos de prueba clonada desde una copia real, nunca la de producción.
  • Pruebas de extremo a extremo que operan la interfaz y leen lo que aparece.
  • Dispositivo Android virtual instalado, operado y observado por el agente.
  • Las pruebas que no pueden correr fallan en voz alta — nunca se saltan en silencio.

Ejemplos hoy

Docker / TestcontainersPlaywrightAndroid EmulatorMaestro

Capa de borde

DNS · TLS · WAF · cache

Servicio entre el visitante y tu servidor que resuelve el dominio (DNS, Domain Name System), termina el cifrado TLS (Transport Layer Security, lo que muestra el candado HTTPS al cliente), filtra peticiones maliciosas con un WAF (Web Application Firewall) y cachea contenido estático cerca del usuario (CDN, Content Delivery Network).

  • Subdominios separados por entorno y por producto.
  • Certificados administrados sin renovación manual.
  • Reglas de redirección y reescritura desde el panel.
  • Filtros automáticos contra ataques de fuerza bruta y bots.

Ejemplos hoy

CloudflareFastlyBunny CDNAWS CloudFront

Entornos escalonados

Desarrollo → validación → producción

Tres niveles aislados: uno donde el agente construye, uno donde el cliente valida sin riesgo y uno donde vive el sistema real con datos reales.

  • Despliegue automático al entorno de desarrollo en cada cambio aprobado.
  • Validación con el cliente en el entorno intermedio antes de tocar producción.
  • Snapshot del servidor antes de cada cambio en producción.
  • Respaldos cifrados fuera del servidor, con simulacro de restauración periódico.

Ejemplos hoy

VPS (Vultr, Hetzner, DigitalOcean)VercelFly.ioAWS / GCP / Azure

Visualizador de modelos de datos

Verificación gráfica

Herramienta gráfica que toma la descripción del esquema y la dibuja: tablas, relaciones, cardinalidades, índices. Sirve para detectar errores que en texto pasan desapercibidos.

  • Confirmar cardinalidades y tablas pivote correctas.
  • Detectar normalizaciones débiles antes de migrar datos.
  • Compartir el diagrama con stakeholders no técnicos.
  • Iterar el modelo con el Coding Agent hasta dejarlo sólido.

Ejemplos hoy

dbdiagram.iodrawSQLLucidchartVertabelo

Una nota sobre la elección concreta de herramientas

Los ejemplos de cada capa son referencias del momento — algunos se popularizarán, otros desaparecerán. Las herramientas cambian, los principios duran. Cuando elijas, hazlo según criterios sostenibles: costo total de propiedad, dependencia de un único proveedor, comunidad activa, tracción comprobada y curva de mantenimiento razonable. Si alguna capa no la puedes cubrir con presupuesto, hay alternativas de software libre o autoalojado para todas — el principio se mantiene.

Formación

Formar un profesional navaja suiza

Si la IA construye y prueba, el rol del desarrollador o experto informático cambia de verdad — y con él debería cambiar la forma en que se lo forma. Desde Evolving creemos que hay que educar a un profesional capaz de levantar una solución informática completa él mismo, con ayuda de una inteligencia artificial: desplegar servidores, publicar en las tiendas de aplicaciones, integrar pasarelas de pago, controlar el gasto. No un especialista profundo en todo, sino alguien que conoce los límites de cada área lo suficiente como para saber qué solución trabajar con la IA.

Por el lado de la gestión

Pasarelas de pago

Qué piden Webpay, Mercado Pago o Khipu para operar con un negocio: contrato, certificación, comisiones, cuándo llega el dinero. Que no sea territorio desconocido el día que el cliente pregunte.

Facturación y gasto en la nube

Contratar un servidor virtual, entender la boleta mensual, poner alertas de costo y saber cuánto cuesta cada gigabyte de respaldo fuera del servidor.

Servicios que se contratan, no se construyen

Facturación electrónica con un proveedor autorizado, correo transaccional, mensajería, mapas, DNS gestionado. Saber cuándo conviene pagar y cuándo conviene hacer.

Viabilidad con IA

Levantar costos, plazos y riesgos de un proyecto con ayuda del agente antes de comprometerse. Un proyecto que no cierra en números se detiene en la semana uno.

Por el lado técnico

Qué tecnología va con qué problema

No dominar cada stack: saber cuál encaja con cada tipo de solución, qué límites tiene y cuánto cuesta mantenerlo. El agente escribe en el que elijas; tú eliges con criterio.

Redes, lo justo y necesario

Puertos, firewalls, qué significa que un servicio escuche en 0.0.0.0, cómo llega una petición desde el navegador hasta el proceso. Lo suficiente para no dejar una base de datos abierta a internet.

Seguridad y resiliencia

TLS, autenticación, respaldos cifrados, snapshots antes de cada cambio y simulacros de desastre. La seguridad de los dispositivos propios incluida.

Publicar y operar

Desplegar un servidor, subir una aplicación a las tiendas de Apple y Google, pasar sus revisiones, firmar los binarios, publicar una actualización sin romper la anterior.

Más teoría de límites, menos sintaxis

Buena parte de esto se enseña de forma teórica: qué se puede y qué no se puede hacer en cada área, qué exige cada servicio, dónde están los riesgos. La sintaxis la pone el agente; el criterio para elegir y para exigir evidencia lo pone la persona.

Varios proyectos reales a la vez

Con un agente que construye y prueba, un estudiante puede llevar dos o tres proyectos informáticos en paralelo — cada uno con su servidor, su pasarela y su despliegue. La amplitud se aprende cubriendo todos los roles muchas veces, no una.

Lo que esto le pide a la universidad

Nada de esto funciona sin acceso real a la herramienta. Una formación así obliga a la universidad a trabajar con alguna de las grandes empresas de inteligencia artificial para proveer licencias a sus estudiantes — como ya empezaron a hacer universidades en Estados Unidos y Europa. Sin licencia, la malla queda en el papel.

Casos

Cuando preguntar revela

Hallazgos reales y anonimizados en sistemas productivos. Los cuatro primeros son de la edición anterior: alguien se detuvo a preguntar lo que parecía obvio. Los tres nuevos son de la era de la evidencia: una suite que «pasaba» sin probar nada, una revisión adversarial que encontró lo que ningún humano habría leído, y el día que un comando borró el sistema operativo de un servidor en producción.

El servidor abierto

Crítico

Tres servicios de base de datos expuestos a internet sin que nadie lo supiera — descubierto al leer la salida de un comando antes de actuar.

El loop fantasma

Latente

Un proceso olvidado golpeaba un endpoint inexistente más de veinte veces por minuto durante meses — encontrado al revisar los registros con calma.

El default silencioso

Activo

Un dominio nuevo servía el panel de login de otro producto — el reverse proxy entregaba su sitio por defecto a cualquier host desconocido.

Los redirects rotos

Latente

Un rebote molesto al loguearse escondía un descenso temporal fuera del cifrado — dos líneas de configuración lo resolvieron.

Las pruebas que pasaban sin probar nada

Activo

Toda la suite de la tienda en línea «pasaba» en verde — porque las pruebas que necesitaban la base de datos se saltaban en silencio cuando faltaba la cadena de conexión.

La revisión adversarial que salvó el libro de ventas

Crítico

Un script de reparación de datos, escrito y probado por el agente, habría puesto en cero la cantidad de las ventas históricas importadas. Lo encontró otro agente buscando refutar el trabajo del primero — no una persona leyendo el diff.

El día que el servidor murió (y volvió en una hora)

Crítico

Un comando de sincronización, copiado para explicar un error, se ejecutó con una variable vacía y borró el sistema operativo del servidor que alojaba tres productos en producción. Snapshots y respaldos verificados lo trajeron de vuelta en menos de una hora.

Leer los 7 casos completos

Cada caso incluye contexto, el hallazgo, la corrección aplicada y la lección extraíble.

Publicaciones

Nueva serie: A merced de la IA, con evidencia

Tres papers que documentan el cambio de paradigma: por qué revisar cada línea dejó de ser posible, qué lo reemplaza (pruebas, entornos simulados, snapshots y simulacros) y qué profesional hay que formar para dirigirlo. Con anécdotas reales de productos en producción — incluido el día que un servidor murió y volvió en una hora — y referencias académicas en formato APA 7. La serie anterior, Atrévete a ser el todo poderoso, sigue disponible.

Audiencia

¿Para quién es este marco?

El contenido es libre y está pensado para quien quiere ser su propio equipo: tanto para quien recién empieza como para quien ya tiene años de oficio. No exige estructura corporativa — una sola persona dirigiendo a su Coding Agent ya es un equipo completo, y el marco escala igual de bien cuando ese equipo de uno crece.

Audiencia primaria

Estudiantes de Ingeniería en Computación e Informática

El grupo donde esta propuesta tiene mayor impacto. Estudiantes que ya conocen los fundamentos y necesitan un marco para dirigir un Coding Agent que construye y prueba — y para convertirse en el profesional navaja suiza que levanta una solución completa: servidor, tienda de aplicaciones, pasarela de pago, respaldos.

Estudiantes de otras carreras

Ingenierías civiles, comerciales, diseño, periodismo y cualquier carrera que requiera construir herramientas digitales propias. La metodología y los casos son útiles aunque la persona no se dedique al desarrollo de software de forma profesional.

Auto-aprendices y reconvertidos

Personas que llegaron al desarrollo desde otros oficios. La IA les permite saltar etapas que antes tomaban años — esta propuesta les da el marco para no perder el rigor que esos años solían enseñar.

Universidades y docentes

Quienes diseñan mallas y cursos de computación. El marco propone qué enseñar cuando la IA escribe y prueba el código — más teoría de límites, varios proyectos reales a la vez — y qué alianza con las empresas de IA hace falta para que los estudiantes tengan licencias.

Profesionales y equipos pequeños

Profesionales que necesitan construir herramientas a medida sin contratar agencias caras. Equipos chicos que quieren acelerar entrega sin sacrificar mantenibilidad.

Organizaciones sociales y proyectos comunitarios

ONGs, fundaciones, colectivos vecinales y proyectos sin fines de lucro que quieren digitalizar procesos críticos sin presupuesto comercial. La velocidad del Coding Agent hace viable lo que antes era inalcanzable.

Una nota sobre los públicos. La división por audiencias es ilustrativa — el contenido es el mismo para todos. Lo que cambia es el punto de entrada: alguien que recién empieza probablemente quiera leer en orden (Filosofía → Metodología → Capas → Casos), mientras que un profesional con años de oficio puede ir directo a los casos para encontrar patrones que reconozca.