El mejor código — el que no hubo que escribir.

Se suele creer que el trabajo del ingeniero comienza donde aparece el código. En la práctica ocurre exactamente lo contrario: la parte más cara del trabajo sucede antes de que se escriba la primera línea.

Hace poco tuve precisamente ese caso: un encargo habitual de freelance que casi se convierte en un producto independiente.

Z tarea en palabras

Sonaba extremadamente simple: tomar la transmisión de un canal de Telegram y mostrarla en el sitio web. Streaming habitual, nada especial — hasta que empiezas a profundizar.

Si se sigue la vía clásica, la solución rápidamente se llena de detalles. Nos conectamos a Telegram a través del stack de cliente, tomamos audio y video por VoIP — PyTgCalls o algo similar, decodificamos Opus y H264, pasamos el flujo por ffmpeg para sincronización y retransmisión, empaquetamos todo en WebRTC o HLS. Y para eso hace falta un servidor aparte que sostenga toda esa construcción.

Tras un par de iteraciones se obtiene un pipeline de medios completo — en complejidad ya está más cerca de un pequeño servicio de streaming que de una “integración simple”.

Aquí comienza la bifurcación.

El enfoque del ejecutor

Se puede aceptar el requisito inicial tal cual: la fuente es Telegram, así que trabajamos con Telegram. Luego entra en juego la honestidad del ingeniero: si los datos llegan por un camino complejo, habrá que repetir ese camino por completo.

Al final el sistema queda así:

Telegram → cliente → decodificación → ffmpeg → WebRTC/HLS → sitio web

¿Funciona? Sí. ¿Es complejo? Sí. ¿Es frágil? También. Y lo más desagradable: habrá que mantener todo exactamente así, con todos los protocolos internos de Telegram, que cambian cuando les venga en gana.

Es ilustrativo que hoy en día cualquier agente de IA recorrerá con gusto todo ese camino. En una noche, con cuidado, siguiendo las mejores prácticas, en ocasiones incluso con pruebas. PyTgCalls, decodificación, sincronización — todo se implementará correctamente. Solo que será una implementación correcta de una solución equivocada. El agente no se pondrá a preguntar si esa es la tarea adecuada: le pidieron resolver exactamente esa, y la resolverá.

La pregunta que rompe la arquitectura

Pero hay otra pregunta, y suena casi maleducada: ¿por qué la fuente tiene que ser Telegram?

A esta pregunta normalmente a nadie le gusta. No es sobre código — es sobre revisar la tarea, no ejecutarla tal cual.

Y aquí se descubre algo sencillo: Telegram en este caso no es la fuente de la transmisión. Es solo un transporte.

Bastó una breve conversación con el propietario del canal para aclarar: el flujo original existe y se puede tomar directamente, sin artimañas.

Todo el complicado esquema se reduce a:

Origen → sitio web

Sin capas intermedias. Sin decodificación VoIP. Sin pelear contra el hecho de que Telegram puede cambiar sus protocolos internos en cualquier momento.

Diferencia de mentalidad

Esta no es una historia sobre Telegram. Es una historia sobre dos formas distintas de pensar.

El enfoque del ejecutor — aceptar las limitaciones como un hecho, construir el sistema alrededor del problema y escribir código.

El enfoque del ingeniero — primero entender de dónde viene el problema, eliminar capas innecesarias y, si es posible, no escribir código en absoluto.

Ambos enfoques dan un resultado funcional. La diferencia está en cuánto costará mantenerlo dentro de un mes.

Conclusión incómoda

En la industria gusta romantizar la escritura de código. Pero en la práctica, el código más eficaz es el que no hizo falta. No porque sea malo, sino porque el sistema se simplificó hasta un nivel en el que dejó de ser necesario.

Antes, renunciar al código sobrante ahorraba semanas de desarrollo. Hoy ahorra una noche de generación con IA — y un año de mantenimiento de lo que esa generación produzca. Escribir código se ha vuelto más barato que nunca. Y el paso que precede al código — más caro.

A veces eso significa que el proyecto no se llevará a cabo: el volumen de trabajo resulta ser varias veces menor de lo planeado.

Pero a largo plazo eso casi siempre significa que no te ahogarás en el sistema que tú mismo construiste.

La ingeniería no es la habilidad de resolver un problema a cualquier precio. Es la habilidad de entender cuándo no vale la pena resolverlo de la forma en que te lo presentaron.