¿Qué es la programación cargo cult?
Cultura de ingeniería y práctica de software
La programación cargo cult es un estilo de desarrollo de software en el que las personas copian código, patrones, herramientas o rituales porque parecen lo que hacen los ingenieros exitosos, no porque entiendan por qué son necesarios. El resultado es un software que tiene la forma de una buena práctica sin el fondo. Puede compilar, incluso puede parecer ordenado, pero el código extra, la ceremonia o la arquitectura a menudo no resuelven ningún problema real y pueden dificultar los cambios futuros.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La mayoría de los ingenieros aprenden por imitación al principio. Eso es normal y, por lo general, saludable. Se observa un ejemplo que funciona, se copia su forma y luego se va comprendiendo el razonamiento sobre la marcha. La programación cargo cult comienza cuando la parte del aprendizaje nunca llega del todo, pero el hábito copiado permanece.
Por eso el término tiene cierta carga. No significa "alguien usó un ejemplo". Significa que alguien mantuvo el ritual después de que la razón había desaparecido. Un equipo añade un bucle de reintentos porque "siempre lo hacemos así". Una base de código lleva diez líneas de código defensivo contra un error que nadie puede describir ya. Una empresa adopta una arquitectura de moda porque una firma admirada la usa, aunque el problema local no se parezca en nada al de ellos.
Por qué importa
Vale la pena entender este término porque describe un modo de fallo que parece respetable desde fuera. El código cargo cult suele llegar vestido con ropas de madurez. Tiene patrones, abstracciones, comentarios, envoltorios y una expresión seria. Eso lo hace más difícil de cuestionar que un trabajo claramente descuidado.
También importa porque el cargo culting no se limita a fragmentos de código. Los equipos lo hacen con procesos, arquitectura, contratación, pruebas y planificación. Las reuniones diarias se convierten en teatro. Los microservicios se convierten en una insignia. Un paso de compilación sobrevive porque eliminarlo parece arriesgado, aunque nadie pueda decir qué protege. Una vez que ese hábito se instala, las organizaciones empiezan a gastar energía preservando rituales en lugar de mejorar el criterio.
Cómo funciona
El origen del término
En la jerga hacker, la programación cargo cult se convirtió en la etiqueta para el código que copia la forma visible de una solución pasada sin entender el mecanismo subyacente. La imagen llegó a la informática a través de la famosa advertencia de Richard Feynman sobre la "ciencia cargo cult", que describía un trabajo que imita la apariencia de una práctica seria sin captar lo que la hace fiable. En el software, la misma idea encaja de manera incómoda. El código tiene el aspecto del oficio, pero no el razonamiento probado.
Hay un matiz importante aquí. La expresión más amplia "cargo cult" tiene una historia colonial y la antropología se ha vuelto mucho más cuidadosa al respecto. Usada con descuido, puede sonar arrogante o despectiva. Por eso, el uso más seguro en ingeniería es estrecho y preciso. Debe apuntar a la imitación vacía, no al aprendizaje de principiantes, ni a las personas como si fueran inherentemente torpes.
Por qué los equipos caen en esto
El software está lleno de causalidades ocultas. Un tiempo de espera de base de datos, una peculiaridad de un framework, una condición de carrera, un error de navegador, una regla de seguridad, una peculiaridad de registro: todos pueden dejar atrás lo que parece un código protector misterioso. Cuando alguien hereda ese sistema, el camino más fácil suele ser conservar el encantamiento y seguir adelante.
La presión empeora esto. Si un lanzamiento está bloqueado, las personas no siempre tienen tiempo para una explicación pausada. Copian la invocación conocida que funciona, esperan que las pruebas pasen y se prometen volver más tarde. Más tarde rara vez llega. El patrón copiado se convierte en folclore. Un ingeniero le dice a otro: "nunca elimines esa línea". La instrucción sobrevive incluso después de que el contexto circundante ha cambiado.
También hay un elemento social. Los ingenieros se ven influenciados por colegas admirados, empresas exitosas y elegantes entradas de blog. Si un equipo respetado usa un patrón, la tentación es importar el patrón antes de entender las condiciones que lo hicieron útil. Así es como las ideas sensatas se convierten en disfraces. La inyección de dependencias, el diseño orientado a eventos, la observabilidad intensiva, los clientes generados, los envoltorios con tipado estricto, los feature flags: todos son válidos en el contexto adecuado. Cualquiera de ellos puede convertirse en cargo cult cuando se adopta como reflejo.
Cómo se manifiesta en el trabajo real
La versión más obvia es el copiar y pegar literal. Alguien toma un bloque de código de otro servicio, una respuesta en un foro o un asistente de IA, lo recorta hasta que el error desaparece y deja el resto en su lugar. Puede haber un bloqueo que nunca se disputa, una comprobación de nulo para un estado imposible, o código de limpieza para un objeto que el entorno de ejecución ya limpia. El sistema carga con un fósil de un problema anterior.
Una versión más sutil aparece en la arquitectura. Un equipo con un producto pequeño y tráfico modesto elige un diseño altamente distribuido porque ha escuchado que los "sistemas serios" usan colas, orquestación, sidecars, mallas de servicios y una elaborada coreografía de despliegue. Meses después, principalmente han creado más lugares donde un cambio sencillo puede perderse. La arquitectura no es incorrecta en abstracto. Es incorrecta para ese momento.
El mismo patrón aparece en los procesos. Una empresa quiere volverse "más orientada a la ingeniería", así que introduce rituales de planificación, puertas de revisión, plantillas y paneles de control. Pronto la gente está rellenando formularios de los que ninguna decisión depende. Esto es cargo culting a escala organizacional. Se han copiado los rituales visibles de la capacidad, pero la toma de decisiones subyacente no ha mejorado.
Una de las pruebas más sencillas es hacer una pregunta directa: ¿de qué problema nos protege esta línea, capa o ritual hoy? Si la respuesta honesta es "no estoy seguro, pero parece peligroso eliminarlo", puede que haya un hábito cargo cult en la sala. Eso no significa que la cosa sea inútil. Significa que el equipo ha perdido la cadena de razonamiento y ahora depende de la superstición.
Ejemplos
Un desarrollador de backend hereda un servicio de pagos. Nota que cada llamada a una API externa está envuelta en tres reintentos anidados, una pausa y una declaración de registro adicional. Nadie puede explicar qué socio necesitaba ese comportamiento ni si ese socio sigue existiendo. Las nuevas llamadas se copian del mismo archivo, por lo que el patrón se propaga. El equipo no está diseñando fiabilidad, la está fotocopiando.
Un equipo de frontend adopta una elaborada biblioteca de gestión de estado porque "los productos grandes la necesitan". Su aplicación tiene un puñado de pantallas e interacciones modestas. Seis meses después, los cambios sencillos en la interfaz requieren ediciones en acciones, reductores, selectores y middleware. La herramienta no falló. El equipo importó la ceremonia antes de tener la complejidad que la hacía valer la pena.
Un responsable escucha que las empresas de alto rendimiento tienen comités de revisión de arquitectura, así que crea uno de la noche a la mañana. Los ingenieros ahora preparan diapositivas para cambios rutinarios de bibliotecas. El comité rara vez dice que no, pero todos aprenden a representar la seriedad. Esto es el primo de la programación cargo cult: la cultura de ingeniería cargo cult.
Malentendidos frecuentes
A menudo se piensa que la programación cargo cult simplemente significa "usar ejemplos". No es así. Copiar un ejemplo que funciona es una de las formas más antiguas y mejores de aprender. El problema comienza cuando lo copiado se conserva sin comprensión ni revisión.
Tampoco es solo un problema de ingenieros junior. Las personas con experiencia hacen cargo culting constantemente, especialmente con arquitectura y procesos. La experiencia puede hacer que el ritual sea más pulido, no menos ritualista.
Otro error es asumir que el cargo culting significa que lo copiado nunca funciona. A veces funciona por suerte, o funcionó una vez por una razón que ya no aplica. Eso es lo que lo hace peligroso. El éxito puede congelar una comprensión deficiente en su lugar.
Por último, no es lo mismo que la estandarización. Los buenos equipos comparten patrones de forma deliberada. Documentan cuándo usarlos, cuándo no usarlos y qué compromisos conllevan. La práctica estándar no es cargo cult si el razonamiento se mantiene vivo.
Riesgos y límites
El término puede usarse mal como insulto de propósito general. Es simplista llamar cargo cult a toda convención o a toda capa desconocida. A veces el ingeniero actual simplemente aún no conoce la historia. A veces una barrera de protección de aspecto extraño existe porque evitó un fallo grave el invierno pasado. Conviene respetar la posibilidad de que lo que parece torpe tenga una historia detrás.
También hay un límite cultural. Dado que la expresión hereda una metáfora cargada, es mejor usarla con cuidado y precisión, no como una broma sobre personas que están aprendiendo. En un equipo saludable, el objetivo es recuperar el porqué, eliminar lo que ya no justifica su presencia y transmitir el razonamiento hacia adelante. La burla no es mantenimiento.
Qué hacer a continuación
Si este patrón resulta familiar, conviene empezar a hacer visible el razonamiento. Pedir a los ingenieros que expliquen no solo qué hace un cambio, sino qué riesgo pretende gestionar. Una nota breve en el código, un registro de diseño ligero o un comentario claro sobre un caso límite conocido pueden evitar que la solución provisional justificada de hoy se convierta en la superstición de mañana.
Hay que recompensar la eliminación tanto como la adición. La forma más sencilla de detectar el cargo culting suele ser eliminar una capa sospechosa y ver qué se rompe en un entorno seguro. Los equipos necesitan permiso para podar, no solo permiso para acumular.
También ayuda separar el aprendizaje del endurecimiento en producción. Está bien empezar con un ejemplo copiado. No está bien publicar código misterioso copiado sin una revisión deliberada de para qué sirve cada parte. Conviene hacer de "explica esto en lenguaje claro" parte de la revisión de código, especialmente cuando aparecen importaciones, envoltorios de framework, código generado o fragmentos escritos por IA.
¿Tiene alguna pregunta o sugerencia, o quiere entender cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿La programación cargo cult es lo mismo que la programación de copiar y pegar?
No exactamente. Copiar y pegar es una vía común para llegar a ella, pero el cargo culting también puede implicar copiar ciegamente arquitectura, procesos, esquemas de nomenclatura o rituales de prueba.
¿Puede funcionar el código cargo cult?
Sí, y por eso sobrevive. Puede funcionar por casualidad, funcionar por una razón obsoleta o funcionar añadiendo complejidad innecesaria.
¿Usar un framework es programación cargo cult?
No. Usar un framework es ingeniería normal. Usarlo porque parece serio, ignorando si se adapta al problema, es donde comienza el cargo culting.
¿La IA hace esto mejor o peor?
Ambas cosas. La IA puede explicar código desconocido, pero también puede generar código repetitivo plausible que los equipos aceptan demasiado rápido. Copiar rápido aumenta la necesidad de un criterio más pausado.
¿Cómo se detecta el cargo culting en la revisión de código?
Preguntando contra qué protege cada capa adicional, si ese riesgo sigue existiendo y qué pasaría si el código se eliminara en un entorno de prueba.
¿Existe un opuesto saludable?
Sí. No se trata de inventar todo uno mismo. Se trata de entender lo suficiente para elegir de forma deliberada y luego mantener el razonamiento visible para la siguiente persona.
Fuentes
Cargo Cult Science (Caltech Library). The underlying idea of copying the form of a practice while missing the thing that makes it trustworthy.