El nuevo junior infinito: qué sí y qué no hace la IA en tu equipo

Intro: cuando tu “compa” nuevo tira código a lo loco

Son las 11:47 pm. Ya te comió el deadline. Tu laptop ya pide esquina, el ventilador suena como si fuera a despegar del AICM, y el build truena por algo que jurabas que quedó desde la mañana.

Abres el editor, le pides a la IA “arregla el bug” y te regresa 40 líneas nuevas, tres imports que no existen y una genialidad peligrosa: verify=False “nomás para pruebas”.

Ahí cae el veinte: la IA sí ayuda un montón… pero si la tratas como senior, te va a meter en broncas como junior con exceso de confianza.

Qué vas a sacar de aquí

• Qué tareas sí conviene delegarle a la IA (y por qué esas, no otras).
• Qué NO deberías delegar (aunque te lo venda bonito).
• Un workflow real de “IA como junior infinito” sin apagar el cerebro.
• Prompts que funcionan para código, pruebas y debugging.
• Errores comunes (los que cuestan horas o un incidente en production) y cómo evitarlos.

Contexto práctico: la IA no es dev, es un acelerador con amnesia

Piénsalo como si te hubieran asignado un junior infinito que:

• Es rapidísimo escribiendo y no se cansa.
• Leyó medio internet, pero no sabe qué parte aplica a tu repo.
• No tiene contexto real: no vivió tu onboarding, no vio el incidente del viernes, no sabe que ese endpoint lo consume una app legacy que nadie se atreve a tocar.
• Confunde “suena correcto” con “es correcto”.

En equipos reales, el tema no es si “sirve o no”. El tema es si la metes a tu stack con un proceso decente o si la dejas generar basura elegante que luego te toca mantener en guardia.

La decisión práctica es bien simple: ¿la IA va a ser tu junior infinito o tu fábrica de PRs ruidosos? Eso lo defines tú con límites y disciplina.

Guía principal: úsala como junior infinito (pero con reglas)

Regla 0: la IA escribe, tú decides

La IA propone. Tú te haces responsable.

Si tu repo toca clientes, pagos, datos personales o algo que te pueda explotar en production, piensa así:

“Gracias por el borrador. Lo reviso como PR de alguien nuevo.”

1) Dale contexto mínimo pero suficiente

Sin contexto, alucina. Con demasiado contexto, filtras cosas o pierdes tiempo (y a veces las dos).

Contexto útil (buena señal):

• Estructura del proyecto (carpetas relevantes).
• Convenciones del equipo (lint, naming, patrones).
• Requisitos claros (inputs/outputs, casos borde, performance).
• Fragmentos del repo (solo lo necesario).

Contexto riesgoso (mala señal):

• Tokens, llaves, credenciales, dumps de prod.
• Archivos completos “por si acaso”.

Prompt base (cópialo y ajusta):

Actúa como junior dev. Te voy a pedir cambios pequeños.

Repo: Node + TypeScript.
Convenciones: no usar any, preferir funciones puras, tests con Jest.

Objetivo: agrega validación al payload de POST /orders.
Casos borde: price debe ser > 0, currency solo MXN|USD.
No cambies comportamiento existente fuera de esta ruta.

Código actual (fragmento):
...

Devuélveme:
1) propuesta breve
2) diff sugerido
3) tests
4) riesgos

2) Pídele entregables como si fuera PR

Si solo le dices “haz X”, te entrega “X pero con sorpresas”. En chamba real, eso es como un freelance mal cotizado: te resuelve algo y te deja tres pendientes escondidos.

Pídele siempre:

• Diff o cambios puntuales.
• Tests (mínimo: happy path + borde + error).
• Riesgos (qué podría romper).
• Alternativas (si hay tradeoffs).

Ejemplo para refactor seguro:

Quiero refactor de esta función para legibilidad.
Restricciones:
- mismos inputs/outputs
- no cambies nombres públicos
- agrega tests que cubran el comportamiento actual antes de tocarlo

Aquí está la función:
...

3) Úsala donde es fuerte (sí conviene)

Aquí es donde normalmente paga su renta.

A) Boilerplate con reglas claras

• DTOs, modelos, mappers, types.
• Endpoints repetitivos.
• Scripts de migración (pero con verificación).

B) Tests y casos borde
Es buena para decirte “también se rompe cuando…”. Tú decides si aplica o es puro ruido.

Ejemplo para generar casos:

Dame una tabla de casos de prueba para esta función.
Incluye: nombre del caso, input, output esperado, y por qué existe.
Función:
...

C) Debug asistido (con evidencia)
Funciona mejor cuando le das señales del mundo real:

• stack trace
• logs
• pasos para reproducir
• “qué debería pasar vs qué pasa”

Prompt para debugging que no se vuelve humo:

Tengo este error en production:
- Stack trace: ...
- Request ejemplo: ...
- Qué esperaba: ...
- Qué pasó: ...

Dame 3 hipótesis ordenadas por probabilidad.
Para cada una: cómo confirmarla (comando/log) y un fix mínimo.

D) Documentación que sí se usa
READMEs, runbooks, notas de deploy, “cómo levantar en local”.

Ojo: revisa. La IA inventa pasos con la seguridad de alguien que solo vio un curso a medias y nunca levantó el proyecto en una máquina vieja.

4) Ponle límites donde es mala (no conviene)

Donde más seguido te mete el pie:

A) Arquitectura sin contexto real
Te propone microservicios cuando tú solo necesitabas un módulo y un buen test.

B) Seguridad por default (spoiler: no)
Puede “arreglar” CORS abriéndolo a todo, o desactivar verificación TLS porque “estorba”. Eso en production no es shortcut: es incidente.

C) Lógica de negocio ambigua
Si la regla no está escrita, la IA la inventa. Y lo peor: suena convincente.

D) Cambios grandes sin red de seguridad
Sin tests, observabilidad o feature flags, es darle un chango con navaja a tu repo.

Decisión práctica: cuando sea “alto impacto”, cambia el juego a:

• primero tests
• luego cambio mínimo
• luego monitoreo

5) Workflow recomendado (para chamba real, no demo)

1. Define el objetivo en una línea (qué cambia y qué no).
2. Pega solo el código relevante.
3. Pide propuesta + diff + tests + riesgos.
4. Corre local: lint + unit tests.
5. Revisa como PR de junior:
   • nombres
   • duplicación
   • manejo de errores
   • performance obvia
   • seguridad
6. Si toca producción: feature flag, logs, métricas, rollback.

Vida real: hay equipos donde el CI tarda 25 minutos y el internet de la oficina se muere cuando llueve. La IA te ayuda a llegar con el cambio más armado antes de picarle a “Create pull request”. Pero no te brinca el pipeline, ni te regala criterio.

Prompts que sí jalan (y por qué)

Prompt “junior disciplinado”

Sirve para que no se vaya en freestyle.

Eres junior dev en mi equipo.
No asumas dependencias nuevas.
Si necesitas algo, pregunta primero.
Devuelve cambios mínimos.
Incluye tests.

Prompt “reviewer mala onda”

Buenísimo para hacerte la auditoría antes de que te la haga alguien más (o peor: el bug en production).

Revisa este diff como reviewer estricto.
Lista:
- bugs potenciales
- edge cases no cubiertos
- problemas de seguridad
- deuda técnica
- sugerencias concretas
Diff:
...

Prompt “hazlo observable”

Para evitar el clásico “ya quedó” y luego nadie sabe qué pasó.

Agrega logging/metrics a este flujo.
Condiciones:
- no incluir datos sensibles
- logs estructurados
- incluye ejemplo de log y métricas sugeridas
Código:
...

Screenshots sugeridos

• Captura del prompt “junior disciplinado” y la respuesta con diff + tests.
• Captura del stack trace y la lista de hipótesis ordenadas.
• Captura del checklist de PR (GitHub/GitLab) con puntos de seguridad.
• Captura del before/after de una función refactorizada con tests pasando.

Errores comunes (con solución en corto)

1) “Le pedí que arreglara el bug” y cambió media app

Síntoma: diff enorme, cambios en archivos que ni venían al caso.

Solución: pide cambio mínimo y delimita archivos.

Solo puedes modificar: src/routes/orders.ts y src/services/orderService.ts.
Si crees que se necesita más, argumenta primero.

2) Te inventa APIs, funciones o imports

Síntoma: import { fancyHelper } from 'utils'… que no existe en ningún lado.

Solución: dile que solo use símbolos existentes y que te diga de dónde los sacó.

No inventes helpers. Si usas una función, dime el archivo exacto donde existe.

3) Soluciones inseguras disfrazadas de “rápido”

Síntoma: disable auth, verify=false, sanitización de utilería.

Solución: pon reglas de seguridad explícitas desde el prompt.

Prohibido desactivar validaciones de TLS, auth o permisos.
Si hay tradeoff, propón una alternativa segura.

4) Tests que pasan pero no prueban nada

Síntoma: asserts flojos, mocks que tapan el bug real.

Solución: pide pruebas enfocadas a comportamiento observable.

Los tests deben fallar si se rompe la validación del payload.
Incluye al menos un caso negativo por cada regla.

5) Te vuelve dependiente y dejas de entender el código

Síntoma: el cambio “funciona” pero no lo puedes explicar ni en 60 segundos.

Solución: exige explicación en términos de soporte y operación.

Explícame el cambio como si yo fuera a dar soporte on-call.
Qué logs vería, qué errores posibles hay y cómo se diagnostican.

Checklist final (antes de merge)

• El cambio está limitado al objetivo (no “refactor accidental”).
• Hay tests: happy path + errores + casos borde.
• No hay secretos en prompts, commits ni logs.
• Seguridad intacta: auth, permisos, validaciones, TLS.
• Lint/format pasan.
• El diff es entendible: nombres claros, sin magia.
• Hay plan de rollback si toca producción.
• Puedo explicar el cambio en 60 segundos.

FAQ

1) ¿Entonces la IA sí reemplaza a un junior?

No. Reemplaza tareas de junior bajo supervisión. Si no hay revisión, se vuelve “junior sin mentor” y eso siempre sale caro.

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

La mejor es la que se integra a tu workflow sin fricción y donde puedas controlar contexto. Si tu equipo vive en PRs, prioriza lo que ayude a escribir y revisar con disciplina.

3) ¿Cómo evito filtrar secretos al usar IA?

Regla de oro: nunca pegues tokens/keys, dumps de prod ni .env. Usa ejemplos falsos, redacta datos y, si puedes, configura políticas de datos para tu org.

4) ¿La IA sirve para debugging en producción?

Sí, si le das evidencia (logs, stack traces, repro). No, si esperas que adivine. Úsala para hipótesis y planes de confirmación.

5) ¿Qué hago si el código que propone “funciona” pero se siente raro?

Trátalo como PR sospechoso: reduce el cambio, agrega tests que definan el comportamiento, y pide una alternativa más simple. Si no puedes explicarlo, no lo merges.

Siguiente episodio

Vamos a convertir prompts bonitos en un workflow repetible: plantillas, snippets y reglas para que tu IA no se salga del carril.

Porque el problema no es pedirle ayuda: es lograr que esa ayuda no te cobre intereses.