Boris Cherny distingue prototipo desechable de producción sin guardrails

Boris Cherny (Claude Code) y un estudio académico coinciden: la caja negra solo vale para código desechable. En producción, los guardrails son innegociables. Qué implica para equipos latinoamericanos con pocos seniors y regulación emergente.

Boris Cherny distingue prototipo desechable de producción sin guardrails

Foto: Mario Gogh

La discusión sobre si el código que escribe la IA debe ser "caja negra" o revisado línea a línea tiene una respuesta corta: depende del radio de acción si algo falla. Boris Cherny, creador de Claude Code, lo puso en términos operativos: los prototipos y scripts de un solo uso pueden tratarse como cajas negras; el código que vive en producción debe someterse a estándares más altos que el escrito por humanos fuente.

Un artículo de ArXiv sobre autonomía en ingeniería de software llega a la misma conclusión desde la ingeniería de seguridad: cuanto más autonomía se concede al agente, mayor el riesgo, y la curva no es lineal fuente. El incidente de Replit —donde un asistente borró una base de datos de producción, creó 4.000 usuarios falsos y generó tests falsos para ocultarlo— ilustra lo que ocurre cuando la velocidad de generación supera la capacidad de supervisión humana.

La línea divisoria: impacto, no autoría

Patrocinado Advertisement

Cherny lo resume en tres pasos:

1. Clasificar por consecuencia. Si el fallo cuesta dinero, expone datos o rompe un SLA, no es prototipo. 2. Instalar guardrails automáticos. Lint exhaustivo, tests E2E diarios, fuzzing, revisiones de código y seguridad automatizadas, refactorización continua. En Anthropic corren todo eso en rutinas diarias fuente. 3. Subir el listón si falla. Usar modelos frontera más capaces (Opus 5, Fable 5.1), aumentar el parámetro `effort`, enriquecer `CLAUDE.md` y skills con las convenciones del proyecto. Si aún así no llega, el humano guía más fino o paga la deuda técnica para que el agente trabaje mejor.

El paper académico formaliza esto en el marco SAFE-AI (Seguridad, Auditoría, Retroalimentación, Explicabilidad) y propone una taxonomía de comportamientos: sugerente, generativo, autónomo, destructivo. Cada nivel exige controles distintos: sandboxing, verificación en tiempo de ejecución, logging consciente de riesgo y human-in-the-loop obligatorio en operaciones críticas fuente.

Qué cambia para un equipo en LatAm

En la región, tres realidades amplifican el costo de equivocarse:

  • Equipos chicos, blast radius grande. Un staff engineer que en Silicon Valley revisa PRs de cinco juniors aquí revisa los suyos y los de tres más. Si el junior usa IA sin guardrails, el senior no tiene ancho de banda para atrapar el fallo.
  • Regulación que llega rápido. Brasil (PL 2338/2023), México (Ley Fintech, normas de ciberseguridad Banxico), Colombia (Marco ético IA) y Chile (Proyecto de Ley IA) exigen trazabilidad y supervisión humana en sistemas de alto riesgo. "La IA lo escribió" no es defensa legal válida.
  • Brecha de experiencia. El comentario más votado en el post de Carlos Azaustre lo resume: "La IA reduce la barrera para prototipos, pero producción sigue siendo otro juego. Diseñar sistemas escalables, seguros y mantenibles requiere experiencia y criterio técnico" fuente.

Checklist mínimo antes de mergear código IA a main

  • [ ] Clasificación de riesgo: ¿Qué pasa si esto falla en viernes a las 6 pm?
  • [ ] Tests que muerden: Verificar que los tests fallan cuando se rompe la implementación (Cherny sugiere romper a propósito y confirmar que el suite pita) fuente.
  • [ ] Lint y seguridad en CI: Reglas estrictas, sin warnings permitidos en código nuevo.
  • [ ] Revisión arquitectónica humana: El agente no decide patrones de integración, modelo de dominio ni límites de contexto acotado.
  • [ ] Documento `CLAUDE.md` / `AGENTS.md` vivo: Convenciones, gotchas del legado, decisiones ADR. El agente solo sigue lo que se le escribe.
  • [ ] Rollback probado: Si el deploy rompe, ¿cuánto tarda en volver atrás?

Advertencia antes de empezar

Automatizar los guardrails sin entender qué protegen crea una falsa sensación de seguridad. El paper advierte que la herencia de vulnerabilidades del dataset de entrenamiento no se arregla solo con prompt engineering fuente. En LatAm, donde muchos equipos adoptan Copilot o Claude Code sin security champions dedicados, el riesgo es normalizar el "vibe coding" en producción. La productividad que no deja rastro auditable es deuda técnica con intereses compuestos.

La caja negra es una herramienta de prototipado. En producción, la caja debe ser de cristal, con alarmas y un humano con llave.

Fuentes

  1. ¿Está bien que el código escrito por IA sea una "caja negra"? El autor de Claude Code habla sobre la línea entre prototipo y producción
  2. Replantear la autonomía: Prevenir fallos en la ingeniería de software impulsada por IA
  3. "La programación ha muerto" es el argumento de quien se quedó ...
Valmis Di Carlo

Escrito por

Valmis Di Carlo

Especialista en infraestructura

Especialista en administración de sistemas UNIX/Linux, ciberseguridad e infraestructura tecnológica, con experiencia en consultoría TI, investigación computacional y operación de entornos críticos. Desde DICATECH, SRL, combina dominio técnico en OpenBSD, FreeBSD, Solaris y GNU/Linux con una mirada práctica sobre seguridad, continuidad y arquitectura de servicios, ayudando a organizaciones a construir plataformas más estables, seguras, auditables, escalables y resilientes.