Players La trampa de los prompts: por qué las empresas latinoamericanas necesitan arquetipos, no ingenieros estrella
La IA borró las fronteras entre roles técnicos. El problema real no es quién programa, sino cómo gobiernas el caos que genera cada prompt sin forma, sin versiones y sin auditoría.
Boris Cherny, el ingeniero que lidera Claude Code en Anthropic, soltó una observación incómoda: en su equipo ya no sabe si alguien es "ingeniero", "PM" o "diseñador". La IA borró esas etiquetas. Lo que ve, en cambio, son cinco formas de trabajar que se repiten sin importar el título del cargo. Las llamó prototipador, constructor, barredor, cultivador y mantenedor. La idea tuvo eco inmediato en la comunidad técnica —sobre todo porque plantea una pregunta que a los ejecutivos de tecnología en América Latina les conviene responder antes de que el desorden los alcance: si cualquiera puede programar con IA, ¿quién se asegura de que lo que se produce sea consistente, auditable y escalable?
El problema de fondo no es cómo se nombran los puestos. Es que la industria del software lleva décadas usando el prompt como unidad básica de trabajo con IA, y el prompt es, en esencia, un desastre de gobernanza. Un paper reciente del arquitecto Ramón Labbé lo desmenuza con precisión quirúrgica: el prompt es privado, no tiene versión, no es componible, no se puede auditar. Un equipo de 50 personas operando 200 prompts cada uno acumula el mismo tipo de conocimiento tribal y no documentado que llevó a la ingeniería de software a inventar los contratos formales, las especificaciones y las pruebas automatizadas. Es decir, la IA nos devolvió a la edad de piedra de la programación, solo que con bots escribiendo el código.
Cherny, desde la trinchera de Anthropic, describe esos cinco arquetipos como roles que trascienden el título. El prototipador genera ideas rápido, muchas fallan, pero así se descubre. El constructor lleva esas ideas a producción. El barredor simplifica, elimina funciones muertas, acelera. El cultivador empuja el producto hacia el market fit. El mantenedor garantiza que el sistema no explote cuando crece. La intuición es potente, pero incompleta. Como señalaron varios comentaristas en la discusión que siguió al post original de Cherny, falta un arquetipo que haga lo que ningún modelo de lenguaje puede hacer hoy: mirar el resultado completo y decir "esto está peor que antes". Falta quien decida, quien revise, quien filtre el AI slop —esa acumulación de código mediocre que las herramientas generativas producen cuando nadie las controla.
Aquí es donde el análisis de Labbé se vuelve urgente para cualquier CTO en Latinoamérica. Su propuesta es simple y devastadora: el prompt no sirve como unidad de gobierno corporativo. Ni siquiera el template de código, que es mejor, alcanza. Lo que una empresa necesita es un arquetipo declarativo —un documento con esquema fijo, versionado, revisable por cualquier persona sin ejecutar nada, que describa antes de generar qué debe tener el artefacto, qué estructura y qué criterios de calidad. Labbé lo implementó en un sistema llamado AgentGuard, pero aclara que el mecanismo no depende de esa herramienta: cualquier sustrato con un esquema fijo cumple las seis propiedades que exige una adopción empresarial seria —repetibilidad, componibilidad, revisabilidad, versionabilidad, transferencia de habilidades y trazabilidad de auditoría. De esas seis, el prompt satisface exactamente cero.
Para una empresa latinoamericana que está empezando a integrar agentes de IA en su flujo de desarrollo —quizás un equipo pequeño en Santiago, São Paulo o Ciudad de México— la tentación es dejar que cada ingeniero use su propio prompt, su propia herramienta, su propia receta. Es rápido al principio. Pero la deuda técnica que se acumula es invisible y silenciosa. No hay dos ingenieros que produzcan el mismo resultado partiendo de la misma intención. No hay manera de saber qué versión de qué prompt generó tal función. Y cuando el ingeniero estrella se va, se lleva todo el conocimiento en la cabeza. Eso no escala. Eso, en realidad, es lo que ya pasaba antes de la IA, pero ahora es peor porque el volumen de código generado es monstruoso y nadie lo está revisando con el mismo criterio con que revisaba el código escrito a mano.
Las cinco categorías de Cherny tienen un uso práctico inmediato para cualquier líder técnico en la región: ayudan a diagnosticar qué falta en el equipo sin caer en la trampa de buscar perfiles con etiquetas de moda. Un equipo que solo tiene prototipadores construirá prototipos eternos que nunca llegan a producción. Un equipo dominado por mantenedores terminará optimizando algo que quizás ni siquiera debería existir. Y un equipo sin barredores se ahogará en código muerto que nadie se atreve a eliminar. Pero la lección más profunda es otra: la clasificación no resuelve el problema de fondo si no viene acompañada de una disciplina de forma. Porque una cosa es saber qué tipo de persona necesitas y otra muy distinta es tener la infraestructura para que su trabajo —con IA o sin ella— sea reutilizable, auditable y transferible.
El verdadero riesgo para las empresas latinoamericanas no es quedarse atrás en la adopción de IA. Es adoptarla sin las salvaguardas que la ingeniería de software aprendió a duras penas durante cuarenta años. La función —que el código compile y haga lo que se le pide— es cada vez más barata de obtener. La forma —que ese código se parezca a todo lo demás que produce la organización, que sea mantenible, que pueda ser revisado por alguien que no lo escribió— sigue siendo el cuello de botella. Y como señala Labbé, los modelos de lenguaje siempre van a resolver la función. La disciplina de la forma es lo único que hace que escalar sea posible.