The best code is the one you didn’t have to write.

It is commonly assumed that an engineer’s work begins where the code appears. In practice it’s the opposite: the most expensive part of the work happens before the first line is written.

Recently there was exactly such a case — a typical freelance order that almost turned into a separate product.

The task in words

It sounded extremely simple: take a broadcast from a Telegram channel and show it on a website. Ordinary streaming, nothing special — until you start digging.

If you go the classic route, the solution quickly accumulates details. Connect to Telegram through the client stack, grab audio and video via VoIP — PyTgCalls or something similar, decode Opus and H264, pass the stream through ffmpeg for synchronization and retransmission, package everything into WebRTC or HLS. And for this you need a separate server to hold the whole construct.

After a couple of iterations you end up with a full media pipeline — in complexity it’s closer to a small streaming service than to a “simple integration.”

This is where the fork begins.

Contractor’s approach

You can accept the initial requirement as given: the source is Telegram, so we work with Telegram. Then engineering honesty kicks in: if the data arrives in a complicated way, that path will have to be repeated in full.

As a result the system looks like this:

Telegram → client → decoding → ffmpeg → WebRTC/HLS → site

Does it work? Yes. Is it complex? Yes. Fragile? Also yes. And the most unpleasant thing is — you’ll have to maintain all of this exactly in that form, with all the internal Telegram protocols that change whenever they feel like it.

It’s telling that today any AI agent will willingly go through this whole path. In an evening, carefully, following best practices, sometimes even with tests. PyTgCalls, decoding, synchronization — everything will be implemented competently. Only it will be a competent implementation of the wrong solution. The agent won’t ask whether this is the right problem: it was asked to solve exactly this one, and it will.

The question that breaks the architecture

But there is another question, and it sounds almost rude: why is the source Telegram at all?

People usually don’t like this question. It’s not about code — it’s about revisiting the task, not executing it as-is.

And then a simple thing becomes clear: Telegram here is not the source of the broadcast. It’s just a transport.

One short conversation with the channel owner was enough to find out: the original stream exists, and it can be taken directly, without roundabout constructions.

The whole complex scheme collapses into:

Source → site

No intermediate layers. No VoIP decoding. No fighting with Telegram changing its internal protocol at any moment.

A difference in thinking

This isn’t a story about Telegram. It’s a story about two different ways of thinking.

The contractor’s approach — accept the constraints as given, build the system around the problem, and write code.

The engineer’s approach — first figure out where the problem comes from, remove unnecessary layers and, if possible, don’t write code at all.

Both approaches produce a working result. The difference is how much it will cost to maintain it in a month.

An unpleasant conclusion

The industry likes to romanticize writing code. But in practice the most effective code is the code that wasn’t needed. Not because it’s bad, but because the system simplified to a level where it ceased to be necessary.

Previously, dropping unnecessary code saved weeks of development. Today it saves an evening of AI generation — and a year of maintaining what that generation produces. Writing code has become cheaper than ever. And the step that precedes code is more expensive.

Sometimes this means the project won’t exist: the amount of work turns out to be orders of magnitude less than planned.

But in the long run it almost always means you won’t drown in the system you built yourself.

Engineering is not the skill of solving a problem at any cost. It’s the ability to understand when a task shouldn’t be solved the way it was presented to you.