El dev que sobrevive a la IA: criterio, arquitectura y contexto

La escena: el PR “mágico” que casi tumba producción

Laptop ya con sus años, el ventilador a todo lo que da como vocho en subida. Tú con café del Oxxo, Slack echando humo y el jefe: “¿sí queda hoy, verdad?”

Le sueltas al copiloto/agent: “arregla el bug del checkout”. Te devuelve un diff enorme: formateadito, comentarios bonitos, hasta “tests (según)”. Lo lees por encimita porque se ve pro. Approve. Push. Deploy.

Dos horas después: el cliente de Monterrey no puede pagar con tarjeta. Soporte te marca. Tú viendo logs con cara de “ya valió”. La IA “arregló” el bug… cambiando la lógica de impuestos y rompiendo un edge case de redondeo. Nadie lo pidió. Nadie lo cachó.

Ahí está el golpe de realidad: no gana el dev que más usa IA; gana el que trae criterio, arquitectura y contexto. La IA escribe. Tú te haces responsable.

Qué te llevas de aquí

• Usar la IA como pair programmer sin volverte aprobador de diffs.
• Un marco rápido de criterio para revisar código generado antes del merge.
• Cómo dar contexto correcto (y limitarlo) para que no se invente cosas.
• Un workflow aterrizado: arquitectura + prompts + pruebas + seguridad.
• Red flags de deuda técnica con sonrisa: cuando “se ve bien” pero huele raro.

Contexto práctico: la IA no entiende tu sistema, entiende tu texto

La IA normalmente brilla en:

• Traducir intención a código: “arma un endpoint”, “haz un parser”, “genera un mock”.
• Sacar opciones rápido: “¿qué patrón conviene aquí?”
• Refactors mecánicos: renombres, extraer funciones, migraciones simples.

Y se atora con:

• Invariantes (reglas del negocio: si fallan, pierdes lana).
• Arquitectura viva (lo que el sistema de verdad hace, no lo que promete el README).
• Contexto incompleto (un ticket sin constraints, una función sin su historia).

Escenario clásico en México/Latam: stack híbrido y acuerdos tácitos.

Un microservicio en Go “nuevo”, pero el core sigue en PHP. Front en React, pero el auth vive en un IIS viejito “porque el banco”. La IA no conoce esas cicatrices. Tú sí.

Decisión clave antes de pedirle código: qué rol va a jugar la IA.

• Asistente: tú diseñas, ella ayuda.
• Explorador: ella propone opciones, tú eliges.
• Escribano: ella genera boilerplate, tú revisas fino.
• Auditor: ella busca riesgos, tú verificas.

Si la dejas ser “arquitecto” sin supervisión, te va a vender una solución elegante… que se estrella con tu realidad (deploy, permisos, latencia, equipo, presupuesto, deadline).

Guía principal: criterio + arquitectura + contexto (workflow que sí aguanta)

1) Empieza por invariantes (lo que no se negocia)

Antes del prompt, escribe 3–7 invariantes. Aunque sea en un comentario del PR.

Ejemplo para checkout:

• El total no puede cambiar por “mejoras” de redondeo.
• Impuestos se calculan con reglas por estado y tipo de producto.
• No se reintenta un cobro si el gateway regresó “approved”.
• Un pedido pagado no vuelve a “pending”.

Esto se vuelve tu brújula para revisar lo que escupió la IA.

Prompt útil (plantilla):

Contexto: Tenemos un checkout. Invariantes:
1) ...
2) ...
3) ...
Restricciones: no cambiar firmas públicas, no agregar dependencias nuevas.
Objetivo: corregir bug X.
Entrega: 1) explicación breve 2) diff mínimo 3) tests.
Si falta info, pregunta primero.

Cuando la IA te regrese un refactor gigante, la pregunta no es “¿se ve limpio?”. Es:

¿respetó invariantes y restricciones? Si no, se descarta o se recorta. En corto.

2) Define el “punto de arquitectura” antes de pedir código

No necesitas UML. Sí necesitas una frase que ubique la lógica:

• “Esta app es layered: controller → service → repo.”
• “El dominio manda: el core no depende de frameworks.”
• “Integraciones externas van detrás de una interfaz.”

Regla de oro: si tú no lo explicas en 30 segundos, la IA menos.

Ejemplos de decisión real:

• Si el bug es de impuestos, ¿vive en TaxService o en el OrderAggregate?
• Si hay que cachear, ¿se cachea en borde (API) o en dominio?

Prompt que amarra arquitectura:

Arquitectura actual:
- Controllers solo validan input y llaman servicios.
- Services orquestan y no conocen SQL.
- Repos acceden a DB.

Implementa el fix en la capa correcta y justifica por qué.

3) Dale contexto… con límites (y sin filtrar secretos)

La tentación es pegar 800 líneas “para que entienda”. Resultado típico: confusión, alucinación o una solución promedio que no respeta tu sistema.

Mejor: contexto mínimo viable.

• 1 archivo donde está el bug
• 1–2 archivos relacionados (interfaces, tipos)
• 1 ejemplo real de input/output
• logs/stack trace si existe

Y límites duros:

• No pegues tokens, llaves, PII, dumps de prod.
• Si usas datos reales, sanitiza: cambia correos, nombres, IDs.

Checklist rápido de sanitización:

- ¿Hay access tokens/keys? -> fuera
- ¿Hay datos de clientes? -> anonymize
- ¿Hay URLs internas o IPs sensibles? -> generaliza
- ¿Hay queries con info privada? -> reduce a estructura

Escena real: te cae el “no jala en la sucursal de Puebla” y lo único que tienes es una captura borrosa de WhatsApp. La IA te puede ayudar a armar hipótesis, pero tu jale es conseguir el dato que importa: request real, logs, versión, feature flag, timestamp.

4) Pídele primero un plan y preguntas, no el código

Si la IA brinca directo a codear, va a rellenar huecos con imaginación.

Prompt:

Antes de escribir código:
1) resume el problema en 3 bullets
2) lista suposiciones
3) pregunta lo que falta (máx 5)
4) propone un plan de cambios (archivos y funciones)

Cuando el plan te cierre, ahora sí: “ok, implementa el paso 1”.

Tradeoff real: te toma 3–5 minutos más. Te ahorra 2 horas de rollback y el “¿quién aprobó esto?” en el canal de incidentes.

5) Haz que la IA trabaje por pruebas: red/green/refactor

Si aceptas puro “compila”, estás apostando.

Pídele:

• primero tests que reproduzcan el bug
• luego el fix mínimo
• luego refactor opcional

Prompt:

Necesito TDD:
- Escribe un test que falle con el bug actual.
- No cambies producción hasta que el test falle.
- Luego implementa el fix mínimo.
- Finalmente, refactor si aplica.

Ejemplo (Node + Jest) para un bug de redondeo:

test('no cambia total por redondeo en impuestos', () => {
  const order = { subtotal: 199.99, state: 'NL', items: [{ type: 'general', qty: 1, price: 199.99 }] };
  const total = calculateTotal(order);
  expect(total).toBe(199.99 + 32.00); // ejemplo: impuesto esperado fijo según regla
});

Ojo: el número exacto depende de tu regla. El punto es fijar comportamiento. Si nadie sabe el valor esperado, el bug está mal especificado: regresa a invariantes.

6) Revisión con criterio: matriz rápida para decir “sí” o “no”

Cuando te llega el diff, pásalo por esta matriz. No es romanticismo: son 10 minutos que te ahorran semanas.

A. Correctitud (qué hace)

• ¿Respeta invariantes?
• ¿Cubre edge cases conocidos?
• ¿Qué pasa con inputs raros (nulls, vacíos, moneda, timezone)?

B. Arquitectura (dónde vive)

• ¿La lógica quedó en la capa correcta?
• ¿Metió acoplamientos raros? (controller con SQL, dominio importando SDKs)
• ¿Está creando un “Dios Service”? (500 líneas y creciendo)

C. Operación (cómo se porta en production)

• ¿Afecta performance? (N+1, loops con llamadas remotas)
• ¿Agrega dependencias o config?
• ¿Impacta observabilidad? (logs útiles vs ruido)

D. Seguridad (qué expone)

• ¿Valida input y sanitiza output?
• ¿Evita injections? (SQL, shell, template)
• ¿Maneja secretos correctamente?

Si falla A o D: no se mergea. Si falla B: casi siempre no, o se re-trabaja. Si falla C: depende del SLA, pero mínimo que esté consciente y medido.

7) “Contexto” también es negocio: define el costo del error

No es lo mismo:

• un bug en el home
• que un bug en facturación
• que un bug en nómina

Aterrízalo como nivel de paranoia.

• Bajo: lints + tests + revisión normal.
• Medio: tests + staging con datos representativos + logs.
• Alto (dinero/PII): regresión, doble review, feature flag, rollback plan.

En startups mexicanas pasa mucho: “no hay staging, jefe”. Va. Entonces sube el cinturón con:

• feature flag
• canary release
• logs con correlación
• rollback que no dependa de “a ver si jala”

8) Usa la IA como auditor (no solo como fábrica)

Prompts que sí dan valor:

Para encontrar riesgos:

Revisa este diff con foco en:
- cambios de lógica accidental
- errores de concurrencia
- impacto en performance
- riesgos de seguridad
Devuélveme una lista priorizada con severidad y por qué.

Para checar consistencia con arquitectura:

Estas son las reglas de arquitectura: ...
¿Este cambio las viola? Si sí, sugiere alternativa.

La IA es buena detectando olores (“esto huele a N+1”, “esto rompe SRP”), aunque se equivoque en detalles. Tú confirmas con código, métricas y sentido común.

Screenshots sugeridos

• Captura del PR con el diff resaltando el “cambio accidental” (la línea donde cambió la lógica, no solo estilo).
• Ejecución de tests: uno fallando antes, pasando después.
• Ejemplo de prompt “plan primero” y las preguntas que hizo la IA.
• Un log/trace correlacionado de una transacción (sin datos sensibles).
• Feature flag activado solo para un porcentaje (si aplica).

Errores comunes + solución (los que sí he visto romper cosas)

Error 1: “Se ve bien” como criterio de aceptación

Síntoma: el código está bonito, pero cambió comportamiento.

Solución: invariantes + test que reproduzca el bug. Si no hay test, no hay confianza.

Error 2: Pedir “refactoriza” sin límites

Síntoma: diff gigante, conflictos con otras ramas, y nadie sabe qué cambió.

Solución: “diff mínimo”, “no cambies firmas”, “un archivo a la vez”. Si urge refactor, que sea ticket aparte.

Error 3: Meter contexto incompleto (o demasiado)

Síntoma: inventa funciones, asume frameworks, o ignora reglas internas.

Solución: contexto mínimo viable + arquitectura en bullets + ejemplo real de input/output.

Error 4: Confiar en tests generados sin revisarlos

Síntoma: tests que no prueban nada (asserts flojos), mocks irreales.

Solución: verifica que el test falle antes del fix y que valide comportamiento, no implementación.

Error 5: IA tocando seguridad “de paso”

Síntoma: logs con datos sensibles, validaciones chafas, o atajos que abren un agujero.

Solución: checklist de seguridad y sanitización. Si toca auth/PII/pagos: doble review y rollout controlado.

Checklist final (para sobrevivir a la IA sin apagar el cerebro)

• Escribí 3–7 invariantes del dominio.
• Decidí la capa donde debe vivir el cambio.
• Le pedí a la IA un plan y preguntas antes del código.
• Di contexto mínimo viable (sin secretos ni PII).
• Exigí test que fallara antes del fix.
• Revisé el diff con matriz: Correctitud / Arquitectura / Operación / Seguridad.
• Tengo plan de rollout: feature flag/canary + rollback.
• Documenté el “por qué” del cambio en el PR (dos párrafos, humano).

FAQ

1) ¿Qué le paso a la IA para que no “invente” cosas?

Invariantes + restricciones + ejemplo real de input/output, y pídele que pregunte lo que falta. Si tu herramienta no permite preguntas, reduce el scope: un solo archivo, un solo objetivo.

2) ¿La IA puede decidir arquitectura por mí?

Te puede poner opciones sobre la mesa, pero no conoce tus constraints reales (legacy, deploy, compliance, presupuesto, equipo, deadline). Úsala para comparar alternativas; la decisión final es tuya.

3) ¿Cómo detecto que el código generado trae deuda técnica?

Señales: diffs enormes para cambios pequeños, dependencias nuevas “porque sí”, lógica de negocio en controllers, muchos TODO, tests que solo prueban “no truena”.

4) ¿Qué hago si mi equipo no tiene tiempo para TDD?

Haz “TDD mínimo”: un test que reproduzca el bug y uno de regresión para el caso crítico. No es glam, pero te da un cinturón de seguridad real.

5) ¿Qué herramienta es mejor: Copilot, ChatGPT, Cursor, agentes?

La que se acopla a tu workflow y a tus políticas. Si tu producto toca pagos/PII, prioriza control de contexto, privacidad, auditoría y límites de lo que compartes. La UI es lo de menos.

Siguiente episodio

Vamos a bajar a tierra prompts y plantillas para que la IA trabaje como senior reviewer: detectar riesgos, proponer tests útiles y cuidar arquitectura.

Con ejemplos de PRs que “se ven bien” pero traen la bomba escondida.