¿Qué es "Works on my machine"?
Cultura de ingeniería y práctica de software
"Works on my machine" es la expresión de ingeniería que describe el software que funciona correctamente en el ordenador de un desarrollador pero falla en otro lugar: el portátil de un compañero, un entorno de pruebas o producción. La frase suele apuntar a diferencias de entorno, configuración, datos, temporización, permisos o arquitectura. Puede sonar defensiva, pero en su mejor versión es evidencia útil: la máquina forma parte del error.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
El software nunca se ejecuta en abstracto. Se ejecuta sobre un sistema operativo concreto, con versiones específicas de bibliotecas, rutas de archivos, secretos, cachés, servicios en segundo plano, zonas horarias, configuraciones regionales, permisos y hardware. Dos portátiles que parecen "básicamente iguales" pueden divergir de formas que importan mucho.
Por eso esta frase ha sobrevivido como broma y como advertencia a la vez. La broma es que todos los equipos de software la han escuchado. La advertencia es que la reproducibilidad es parte de la ingeniería, no un extra opcional. Si el código solo funciona en una máquina, esa máquina te está diciendo algo.
A veces la frase se usa mal, como si el éxito local zanjara el debate. Bien utilizada, sin embargo, no es el final de la conversación. Es el inicio de la comparación.
Por qué importa
"Works on my machine" importa porque revela una brecha entre el código y el entorno. Esa brecha es una de las fuentes más comunes de problemas en los despliegues, fricciones en la incorporación de nuevos miembros, pruebas inconsistentes y sorpresas embarazosas en producción. El código puede funcionar bien en una configuración y ser frágil en todas las demás porque sus dependencias reales nunca se hicieron explícitas.
También importa desde el punto de vista cultural. La frase puede volverse defensiva muy rápido. Una persona la interpreta como "tu entorno está mal". Otra la entiende como "no me creo tu informe de error". Si el equipo no trata la frase como un dato en lugar de una actitud, la confianza se erosiona en el proceso de depuración.
Para quienes lideran equipos, es una señal de que la comodidad local y la reproducibilidad compartida se han distanciado. La solución rara vez consiste en pedir a la gente que "pruebe mejor". Los equipos necesitan paridad de entornos, versiones fijadas, instrucciones de configuración claras, consistencia en la compilación, integración continua realista e informes de errores que capturen los datos de la máquina. En otras palabras, la frase apunta a un problema sistémico, no solo individual.
Cómo funciona
Por qué la frase sigue reapareciendo
La razón es sencilla: los desarrolladores prueban primero de forma natural en la máquina que tienen delante. La retroalimentación local es rápida, barata e imprescindible. Pero esa misma velocidad genera suposiciones locales. Una variable de entorno oculta está presente. Una base de datos tiene datos de prueba editados a mano. Una versión de paquete es más reciente. Una caché está caliente. Un sistema de archivos no distingue mayúsculas de minúsculas. Un portátil es x86 mientras que producción es ARM, o al revés.
La integración continua existe en parte precisamente para detectar este tipo de deriva. La paridad entre desarrollo y producción se convirtió en un principio de diseño completo por la misma razón. Los sistemas de compilación en grandes empresas buscan el mismo resultado en todas las máquinas porque cualquier cosa menor se convierte en un caos costoso a escala.
Qué suele causar la discrepancia
Las causas habituales son conocidas: deriva en versiones de dependencias, servicios de respaldo distintos, secretos no declarados, datos locales obsoletos, migraciones pendientes, diferencias en permisos de archivos, problemas de zona horaria y configuración regional, incompatibilidades de arquitectura, y errores que solo aparecen bajo concurrencia real o conjuntos de datos más completos.
A veces el código en sí está bien, pero la compilación no es reproducible. A veces el código depende de un comportamiento que un servicio local proporciona por casualidad, pero producción no lo hace. A veces todos ejecutan el mismo comando, pero no sobre las mismas entradas. "Mismo código" es una garantía mucho más débil de lo que la gente cree.
Cómo los equipos reducen el problema
Los equipos lo reducen haciendo que los entornos sean describibles y repetibles. Fijan versiones, automatizan la configuración, confirman en el repositorio la configuración que es seguro confirmar, modelan la infraestructura como código, usan integración continua para cada cambio propuesto y mantienen desarrollo, preproducción y producción tan próximos como sea práctico.
Los contenedores y las máquinas virtuales ayudan mucho, pero no son mágicos. Los contenedores comparten el kernel del host y siguen dependiendo de la arquitectura y del comportamiento a nivel de host. La integración continua ayuda enormemente, pero no puede representar todas las características de producción. El objetivo no es la identidad perfecta. El objetivo es eliminar las diferencias fáciles e innecesarias para que las diferencias restantes sean visibles y valga la pena discutirlas.
Ejemplos
Un servicio pasa las pruebas localmente porque la máquina del desarrollador tiene un token en un perfil de shell olvidado y una base de datos sembrada hace meses con registros ordenados y permisivos. En la integración continua, el token está ausente y los datos de prueba son más estrictos. El código no empeoró de repente. La máquina local llevaba una ayuda invisible.
Un frontend compila en un portátil Intel y falla en un ejecutor de integración continua basado en ARM porque una dependencia nativa solo era compatible por casualidad en un entorno. Todos juran haber ejecutado el mismo comando. Así fue. El comando no se ejecutó sobre la misma arquitectura.
Un trabajo de informes parece correcto en las pruebas locales, pero discrepa con producción después de medianoche. La máquina local agrupa las fechas en una zona horaria. El servidor las agrupa en otra. La línea de código es idéntica. El reloj que la rodea no lo es.
Malentendidos frecuentes
Un malentendido es que "works on my machine" es siempre una excusa. Puede serlo, pero también puede ser evidencia útil. Si algo solo funciona en un entorno, esa diferencia merece examinarse con cuidado.
Otro es que los contenedores han resuelto el problema. Ayudan de forma notable, pero incluso los flujos de trabajo con contenedores siguen encontrándose con kernels de host, arquitecturas, sistemas de archivos montados, diferencias de red y problemas de gestión de secretos.
También se asume que la integración continua por sí sola es suficiente. Es imprescindible, pero un pipeline en verde no garantiza el comportamiento en producción bajo escala real, tráfico real o patrones de datos reales.
Otro malentendido es que esto es principalmente un problema de ingenieros con poca experiencia. No lo es. Los equipos experimentados acumulan scripts locales, cachés antiguas, personalizaciones de shell y casos especiales con la misma facilidad que cualquier otro.
Por último, hay quienes hablan como si el código y el entorno pudieran separarse limpiamente. En la práctica, el entorno suele formar parte del comportamiento real del programa. Ignorarlo no hace desaparecer la dependencia.
Riesgos y límites
La frase se vuelve perjudicial cuando detiene la conversación. Si un desarrollador la dice queriendo decir "por tanto, el problema es tuyo", el equipo ya está en apuros. El seguimiento saludable es: "bien, ahora comparemos qué es diferente".
También existe un límite a la paridad. No todos los factores de producción pueden ni deben clonarse localmente. La escala real, el tráfico de usuarios reales, los límites de velocidad de terceros y los datos de larga vida y desordenados resisten la replicación ordenada. Perseguir la identidad perfecta puede desperdiciar esfuerzo.
El límite adecuado es la reproducibilidad práctica. Elimina la deriva donde puedas. Registra el resto de forma explícita. Si la diferencia importa, hazla visible en las herramientas, la documentación o la integración continua. Si no puede replicarse localmente, reconócelo y prueba en un entorno más representativo.
La peor versión de "works on my machine" es el folklore defensivo. La mejor versión es una pista empírica que apunta hacia una comparación concreta.
Qué hacer a continuación
Si tu equipo sigue encontrándose con este patrón, estandariza lo básico. Un solo comando debería compilar el proyecto. Un solo comando debería ejecutar las pruebas principales. Las versiones de dependencias deben estar fijadas. La configuración debe vivir en el control de versiones, no en la memoria de alguien ni en sus dotfiles.
Apuesta por describir los entornos como código donde sea práctico. Eso puede significar definiciones de contenedores, configuraciones de máquinas virtuales, manifiestos de paquetes, scripts, datos de inicialización o configuración de integración continua que refleje el desarrollo local con suficiente fidelidad como para ser significativa.
Mejora también los informes de errores. Solicita sistema operativo, arquitectura, versión de la aplicación, rama, versiones de dependencias, variables de entorno relevantes, cambios recientes y pasos para reproducir el problema. Cuando las personas reportan problemas con ese contexto, "works on my machine" se vuelve más fácil de traducir en una diferencia concreta.
Sobre todo, trata la reproducibilidad como parte de la calidad del producto. Afecta a la velocidad de entrega, la tasa de incidentes, la incorporación de nuevos miembros e incluso a la credibilidad que la ingeniería tiene ante el resto de la organización.
¿Tienes alguna pregunta o sugerencia, o quieres entender cómo investigamos y revisamos estas guías? Lee sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿"Works on my machine" es alguna vez útil?
Sí. Indica que el fallo depende de algo fuera de la ruta de código visible, como el entorno, los datos, la temporización, la configuración o la arquitectura. Eso es información valiosa para la depuración.
¿Los contenedores eliminan el problema?
Reducen una gran parte, pero no todo. El comportamiento del host, la arquitectura, los secretos, los archivos montados y los servicios externos pueden seguir difiriendo de formas que importan.
¿Qué debo comparar primero?
Empieza por lo básico: sistema operativo, arquitectura, rama, versiones de dependencias, variables de entorno, estado de la base de datos, migraciones recientes y el comando exacto que se ejecutó.
¿Por qué la integración continua detecta esto con tanta frecuencia?
Porque ejecuta el código en un entorno más limpio y estandarizado. Las suposiciones locales ocultas que pasan desapercibidas en un portátil suelen fallar de inmediato allí.
¿Esto tiene que ver principalmente con desarrollo frente a producción?
No solo. También ocurre entre dos máquinas de desarrolladores, entre el entorno local y la integración continua, entre dos ejecutores de integración continua, y entre una región y otra si la configuración o la infraestructura difieren.
¿Cómo se relaciona esto con las compilaciones reproducibles?
Las compilaciones reproducibles buscan el mismo resultado de compilación a partir de las mismas entradas en cualquier máquina. Ese principio ataca una fuente central del problema de "works on my machine" a nivel de compilación.
Fuentes
An Introduction to DevOps (Carnegie Mellon Software Engineering Institute). Practical explanation of the phrase and how canonical development environments reduce local drift.