The best code — the code you didn't have to write.

There is a persistent illusion 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 regular freelance order that almost turned into a standalone 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 follow the classic route, the solution quickly accumulates details. We connect to Telegram through the client stack, pull audio and video via VoIP — PyTgCalls or something like that, decode Opus and H264, run the stream through ffmpeg for synchronization and retransmission, wrap everything in WebRTC or HLS. And yes, this requires a separate server to hold the whole beast.

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

And here the fork appears.

The contractor’s path

You can take the initial requirement as a given: the source is Telegram, so we work with Telegram. Then engineer honesty kicks in: if the data comes via a complicated route, that route must be repeated in full.

As a result the system looks like this:

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

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

And what’s particularly telling — today that whole path will be happily implemented by any AI agent. In an evening, neatly, following best practices, sometimes even with tests. PyTgCalls, decoding, synchronization — everything will be implemented properly. It will just be a proper implementation of the wrong solution. The agent won’t ask whether this is the right problem — it was asked to solve this one, and it will.

The question that breaks the architecture

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

This question usually pleases no one. It’s not about code — it’s about revising the task, not executing it as given.

And then a simple fact becomes clear: Telegram is not the source of the broadcast here. 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 fetched directly — without all those roundabout constructions.

The whole complex scheme collapses into:

Source → website

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

Difference in thinking

This is not a story about Telegram. It’s a story about two different ways of thinking.

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

The engineer’s approach — first figure out where the problem actually comes from, remove unnecessary layers and, if possible, not write any 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 you didn’t need to write. Not because it’s bad, but because the system simplified to the level where it simply was no longer needed.

Previously “not writing code” saved weeks of development. Today it saves an evening of AI generation — and a year of maintaining whatever that generation produces. Writing code has become cheaper than ever. But the step before it — is more expensive.

And yes, sometimes this means you don’t get the project — because the amount of work turns out to be many times smaller than planned.

But in the long run this almost always means you’re not drowning in the system you built yourself.

Engineering is not about solving problems at any cost. It’s about understanding when a problem shouldn’t be solved the way it was presented to you.