De script a sistema: cuando tu código de Python deja de ser un script

El primer script de Python que escribí en producción tenía 200 líneas, un solo archivo, y funcionaba… hasta que no. Un día cambió el formato de un CSV, otro día falló la conexión a la API, y una semana después nadie sabía quién lo había corrado por última vez ni si había terminado bien.

Ese script hacía exactamente lo que se pedía. El problema era que nadie había pensado en lo que pasa después de que “funciona”.

El punto de inflexión

Hay un momento en el que un script deja de ser una herramienta personal y se convierte en infraestructura que otros dependen de ella. Ese momento no se anuncia. No hay una reunión donde alguien diga “a partir de ahora esto es crítico”. Simplemente empieza a usarse todos los días, y un día falla en el momento equivocado.

Cuando eso pasa, las preguntas que importan no son sobre sintaxis ni sobre qué librería usar. Son sobre:

• ¿Qué pasa si esto falla a las 3 de la mañana?
• ¿Cómo sé si ya corrió hoy?
• ¿Puedo confiar en que los datos que generó están completos?
• ¿Cuánto tiempo tarda alguien nuevo en entender qué hace?

Lo que cambia

Un script es código que resuelve un problema puntual. Un sistema es código que resuelve un problema de forma predecible, observable y mantenible.

La diferencia no está en usar Docker, ni en tener CI/CD, ni en migrar a microservicios. A veces un sistema bien diseñado sigue siendo un script de 300 líneas. Lo que cambia es que alguien pensó en los límites: en qué entradas son válidas, en qué estados puede estar, en cómo se recupera de un error, en cómo se explica a alguien que no lo escribió.

Lo que he aprendido construyendo

En los últimos años he trabajado en herramientas que conectan APIs, transforman datos, orquestan flujos de trabajo y alimentan interfaces conversacionales. Algunas empezaron como scripts de una tarde. Otras fueron sistemas desde el primer commit. En ambos casos, las que sobrevivieron tenían algo en común: alguien se tomó el tiempo de hacer explícitas las decisiones que normalmente se dejan implícitas.

Qué datos entran, qué forma tienen, qué pasa si no llegan, qué pasa si llegan mal, quién puede disparar el proceso, cómo se audita, cómo se recupera. No son detalles secundarios. Son el sistema.

Para quién es esto

Si estás buscando a alguien que escriba Python, hay miles de desarrolladores que pueden hacerlo. Si estás buscando a alguien que piense en qué pasa cuando ese código se encuentra con la realidad de una organización que opera 24/7, que necesita trazabilidad, que no puede permitirse perder datos ni tiempo, entonces estamos hablando de algo distinto.

No se trata de escribir más código. Se trata de escribir el código que necesita existir para que el resto del sistema funcione.