Boilerplate killer: automatiza lo repetitivo sin apagar el cerebro

Llegas tarde al daily. Abres el repo. Y ahí está el ritual de siempre: crear un endpoint nuevo, copiar/pegar validaciones, armar DTOs, meter logs, escribir el test “mínimo”, actualizar Swagger… y rezar para que el linter no te haga bullying.

Eso no es “programar”. Es talacha. Y lo más gacho: lo repetitivo se come justo el tiempo donde sí necesitas pensar.

La idea es usar IA como AI Pair Programmer para matar boilerplate, pero con guardrails. Nada de “hazme toda la app” y luego andar apagando incendios en production. Automatiza lo repetitivo sin apagar el cerebro.

Qué te vas a llevar

• Detectar qué boilerplate sí conviene automatizar (y qué mejor ni toques).
• Armar un workflow reproducible: plantillas + prompts + checks.
• Usar IA para scaffolding, refactors mecánicos, tests, docs y PRs… con control.
• Evitar los tropiezos típicos: código inventado, inconsistencias, riesgos de seguridad y debt disfrazada de “avance”.

El boilerplate que sí duele (vida real)

Boilerplate no es “código feo”. Es código predecible que haces una y otra vez:

• CRUDs y endpoints repetidos.
• Mapeos de DTO ↔ modelo.
• Validaciones y mensajes de error.
• Configs (env, docker, CI, linters).
• Tests de contrato y casos “de cajón”.
• Glue code: adapters, clients, wrappers.

Y en equipos reales se siente más porque:

• El onboarding fue: “ahí está el Notion… suerte, banda”.
• Traes una laptop ya cansada, el build tarda, y tu Wi‑Fi decide fallar justo cuando jalas deps.
• El jefe o el cliente te pide “un endpoint más” para ayer, pero “bien probado” y “sin tocar nada”.

Ahí una IA bien usada te ahorra horas. Mal usada te deja una bomba de deuda técnica con moñito.

Workflow “Boilerplate killer” (con IA y sin caos)

Regla de oro: primero estandariza, luego automatiza. Si tu repo no tiene convenciones, la IA va a improvisar… y tú vas a pagar el rollback.

1) Define la “receta” del patrón (antes de pedirle nada a la IA)

Agarra un ejemplo que ya esté bien hecho y conviértelo en checklist.

Ejemplo (API típica):

• Ruta + handler/controller
• Validación de input
• Servicio/caso de uso
• Repositorio/DAO
• Mapeos
• Logging
• Tests unitarios + de integración
• Documentación (OpenAPI/Swagger)

Tu tarea: bajarlo a 10–15 bullets en algo como docs/patterns/new-endpoint.md. Ese doc es tu “contrato” para la IA.

Decisión práctica: si no puedes describir el patrón en bullets, todavía no estás listo para automatizarlo.

2) “Plantillas vivas”: snippets y archivos base

Aquí hay ganancia inmediata sin depender 100% del modelo:

• Snippets en tu editor (VS Code) para estructuras repetidas.
• Templates de archivos (ej. __tests__/, routes/, schemas/).
• Un generador simple (plop, hygen, cookiecutter) si el proyecto ya lo amerita.

Ejemplo rápido con Hygen (Node/TS) para generar un endpoint:

npx hygen endpoint new --name createUser --resource users

Y tu plantilla mete:

• src/routes/users.ts
• src/controllers/users/createUser.ts
• src/schemas/users/createUser.schema.ts
• src/services/users/createUser.service.ts
• src/__tests__/users/createUser.int.test.ts

Dónde entra la IA: en ayudarte a escribir o ajustar esas plantillas para que calcen con tu estilo y con el repo real (sin inventarse cosas).

3) Prompt que sí jala: contexto + límites + formato

Un prompt útil no es “genera el endpoint”. Es una instrucción de taller, con reglas.

Prompt base (cópialo y ajústalo)

Actúa como mi AI Pair Programmer. No inventes librerías ni archivos que no existan.

Contexto:
- Stack: Node.js + TypeScript + Express
- Validación: zod
- Tests: vitest + supertest
- Convenciones del repo:
  - controllers no acceden a DB directo
  - servicios regresan Result<T, E>
  - logs con pino (logger.info/error)

Tarea:
Quiero agregar el endpoint POST /users para crear usuario.

Input:
- email (string, email)
- name (string, min 2)

Output:
- 201 con { id, email, name }
- 409 si email ya existe

Requisitos:
- Genera SOLO los cambios necesarios.
- Devuelve en formato patch (diff) por archivo.
- Incluye tests de integración.
- Si falta información, pregunta antes de asumir.

Referencia:
Te paso el código actual de un endpoint similar: POST /projects (incluyo archivos...)

Tradeoff real: pedir “diff por archivo” baja el caos. Pedir “dame todo el proyecto” es receta para inconsistencias y sorpresas.

4) Flujo de trabajo para no romper production

1. Dale a la IA un ejemplo existente (1 endpoint similar) + tu receta del patrón.
2. Pide primero esqueleto (archivos + firmas) sin lógica compleja.
3. Revisa nombres, rutas, imports, y que no meta dependencias fantasmas.
4. Luego sí: validación, service, repo, manejo de errores.
5. Corre:
   • lint
   • typecheck
   • tests
6. Ya que todo está verde, pide “acabados”: mensajes de error, logs, docs.

Modo realista (y efectivo):

• Iteración 1: “que compile”
• Iteración 2: “que pase tests”
• Iteración 3: “que quede consistente”

5) Refactors mecánicos: donde la IA brilla

Cuando el cambio es repetitivo pero delicado (y da flojera), la IA te ahorra horas:

• Renombrar campos y propagarlo sin romper tipos.
• Migrar de axios a fetch en clients.
• Convertir callbacks a async/await.
• Extraer una función común.

Prompt para refactor más seguro:

Necesito un refactor mecánico.

Objetivo:
- Renombrar `userId` a `accountId` en todo el repo.

Reglas:
- No cambies comportamiento.
- Respeta TypeScript.
- Devuelve lista de archivos afectados + diff.
- Señala riesgos (migraciones, DB, logs, analytics).

Escena típica: te lo piden en corto porque “es nomás un rename”, y luego truena un reporte porque se te fue un string en analytics. Este tipo de prompt reduce esos misses.

6) Tests: la IA como multiplicador, no como juez

Si la dejas “inventar” tests sin conocer tu setup, te entrega:

• mocks irreales
• datos que no pasan validación
• tests verdes que no prueban nada

Mejor:

• Tú defines qué casos importan.
• La IA escribe el pegamento repetitivo.

Checklist para POST /users:

• 201 crea usuario
• 409 si email duplicado
• 400 si email inválido
• 400 si name corto

Si ya tienes supertest, pide integración: valida routing + middlewares + validación. Eso te protege cuando alguien mete un “pequeño cambio” y se lleva puesto el comportamiento.

7) Documentación y PRs: aburrido, pero te salva el deadline

Cuando ya compila y pasa tests:

• Pídele a la IA actualizar OpenAPI/Swagger con ejemplos reales.
• Pídele un summary de PR:
  • qué cambió
  • cómo probar
  • riesgos

Prompt para PR description:

Genera un PR description en español (tono técnico y claro) con:
- Resumen
- Cambios principales
- Cómo probar (comandos)
- Consideraciones de seguridad
- Posibles regresiones
Usa bullets. No inventes features.

Esto vale oro con equipo remoto, y también si andas de freelance y quieres que el cliente vea workflow, no “magia”.

Screenshots sugeridos

• VS Code con el diff por archivos (antes/después) del endpoint nuevo.
• Terminal corriendo pnpm test o npm run test con el suite pasando.
• Fragmento del OpenAPI/Swagger con el POST /users documentado.
• Estructura de carpetas mostrando el patrón (controller/service/schema/test).

Errores comunes (y cómo salir del hoyo)

1) La IA inventa librerías o archivos

Síntoma: imports que no existen, “ya tienes tal middleware”, pero nel.

Cómo lo arreglas:

• Regla explícita: “No inventes dependencias ni archivos”.
• Pásale package.json y el árbol de src/ relevante.
• Exige que pregunte si falta info.

2) Código “casi igual” que rompe convenciones

Síntoma: controllers con lógica de negocio, servicios hablando con req/res, etc.

Cómo lo arreglas:

• Dale un endpoint “golden path” como referencia.
• Pide un primer pase solo de estructura y firmas.
• Si viola el patrón, se rechaza y ya. No se negocia.

3) Tests verdes pero fake

Síntoma: mockean todo y al final no estás probando nada real.

Cómo lo arreglas:

• Prioriza integración cuando puedas.
• Exige asserts relevantes (status + body + efecto en DB si aplica).
• Haz la prueba del ácido: rompe algo a propósito y confirma que un test falle.

4) Seguridad: logs con datos sensibles o validaciones flojas

Síntoma: logs con emails completos, tokens o payloads enteros.

Cómo lo arreglas:

• Define política: qué se loggea y qué se redacted.
• Pídele “security review” a la IA, pero tú decides.
• Si hay auth, valida scopes/roles explícitamente.

5) Automatizaste y ahora nadie entiende el generator

Síntoma: solo una persona sabe correrlo; se va, y el jale se vuelve ruleta.

Cómo lo arreglas:

• Documenta npm run gen:endpoint en el README.
• Deja ejemplos y opciones.
• Mantén plantillas pequeñas y legibles.

Checklist final (matar boilerplate sin matar calidad)

• El patrón vive en docs/ con bullets claros.
• Tengo un endpoint de referencia “golden”.
• La IA trabajó en diffs por archivo, no en “código suelto”.
• No se agregaron dependencias sorpresa.
• Corren lint, typecheck y tests en local/CI.
• Hay tests para casos felices y errores.
• Logs sin datos sensibles.
• Docs/API spec actualizada.
• PR description con pasos de prueba y riesgos.

FAQ

1) ¿Esto aplica si no uso Copilot y solo uso ChatGPT/Claude?

Sí. La clave no es la marca: es el formato de trabajo (referencia + receta + diffs + checks). Si puedes dar contexto y recibir cambios estructurados, jala.

2) ¿Qué boilerplate NO conviene automatizar?

Lo pegado a decisiones de negocio o riesgo alto: pricing, permisos finos, flujos de pago, criptografía, migraciones delicadas. Ahí la IA apoya, pero no manda.

3) ¿Cómo evito que la IA meta código inseguro?

Pon límites: no loggear PII, no concatenar SQL, validar input estricto, y revisa dependencias. Úsala como si fuera un junior rapidísimo: útil, pero requiere review.

4) ¿Vale la pena un generador (Hygen/Plop) si el proyecto está chico?

Si vas a crear 1–2 endpoints, tal vez no. Si ya vas en el 5to y cada uno te cuesta 1–2 horas de repetición, el generador se paga solo. Señal clara: te da flojera porque “es lo mismo”.

5) ¿Cómo mido si mi boilerplate killer está funcionando?

Mide tiempo de ciclo: de “necesito endpoint” a “PR listo”. Si bajó y no subieron bugs/regresiones, vas bien. Si bajó pero ahora todo quedó inconsistente, automatizaste demasiado pronto.

Siguiente episodio

Vamos a ponerle colmillos a la IA con guardrails de calidad: linters, pruebas y políticas para que el copiloto no se convierta en “caos con autocompletado”.

Spoiler: el verdadero boost no es escribir más rápido… es romper menos cosas.