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

Existe una persistente ilusión de que el trabajo del ingeniero comienza donde aparece el código. En la práctica es todo lo contrario: la parte más cara del trabajo ocurre antes de que se escriba la primera línea.

Recientemente ocurrió justamente eso — un encargo típico de freelance que casi se convirtió en un producto independiente.

Tarea en palabras

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

Si se sigue el camino clásico, la solución pronto se llena de detalles. Nos conectamos a Telegram a través del stack de cliente, sacamos audio y vídeo por VoIP — PyTgCalls o algo por el estilo, decodificamos Opus y H264, pasamos el flujo por ffmpeg para sincronizar y retransmitir, envolvemos todo en WebRTC o HLS. Y sí, para esto hace falta un servidor separado que mantenga todo ese zoológico.

Tras un par de iteraciones se obtiene una canalización de medios completa — por su complejidad ya está más cerca de un servicio de streaming pequeño que de una «integración simple».

Y aquí comienza la bifurcación.

El camino del ejecutor

Se puede tomar el requisito inicial como un hecho: la fuente es Telegram, entonces trabajamos con Telegram. Y entonces entra en juego la honestidad ingenieril: 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

¿Funciona? Sí. ¿Complicado? Sí. ¿Frágil? También sí. Y lo más desagradable es que habrá que mantener todo esto exactamente igual, con todos los protocolos internos de Telegram, que cambian cuando les parece.

Y lo más ilustrativo: 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 tests. PyTgCalls, decodificación, sincronización — todo se implementará correctamente. Simplemente será una implementación correcta de la solución equivocada. El agente no va a preguntar si esa es la tarea correcta — le pidieron resolver exactamente esa, y la resolverá.

La pregunta que rompe la arquitectura

Pero hay otra pregunta, y suena casi grosera: ¿por qué la fuente es Telegram en primer lugar?

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

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

Bastó una conversación corta con el propietario del canal para aclarar: existe un flujo original, y se puede tomar directamente — sin todas esas construcciones indirectas.

Todo el esquema complicado se reduce a:

Fuente → sitio

Sin capas intermedias. Sin decodificar VoIP. Sin luchar contra que Telegram cambie su protocolo interno en cualquier momento.

Diferencia en la forma de pensar

Esto no es una historia sobre Telegram. Es una historia sobre dos formas diferentes de pensar.

El enfoque del ejecutor — aceptar las limitaciones como datos, construir el sistema alrededor del problema y codificar la solución.

El enfoque del ingeniero — primero entender de dónde viene el problema, quitar 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 efectivo es el que no hizo falta. No porque sea malo, sino porque el sistema se simplificó hasta un nivel en el que simplemente dejó de ser necesario.

Antes, «no escribir código» ahorraba semanas de desarrollo. Hoy ahorra una noche de generación por IA — y un año de mantenimiento de lo que esa generación produzca. Escribir código es más barato que nunca. Pero el paso previo a ello — es más caro.

Y sí, a veces eso significa que no consigues el proyecto — porque el volumen de trabajo resulta ser mucho menor de lo planeado.

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

La ingeniería no va de resolver tareas a cualquier precio. Va de entender cuándo no vale la pena resolver la tarea de la manera que te han traído.