By Editorial — IT Researches
When we started doing computer vision work in 2011, every system was a stack of OpenCV primitives held together by domain knowledge. By 2018, the default reflex had inverted: every problem was a fine-tuning exercise on top of a pre-trained network. By 2025 the pendulum has settled, and the interesting question is no longer which approach is fashionable but which approach fits the problem.
Classical computer vision still wins reliably under three conditions. First, when the geometry of the scene is known and stable: barcode reading, fiducial detection on a production line, dimensional measurement under controlled lighting. Second, when the rules of the problem can be written down: counting items in a grid, detecting circular features with a known radius range, tracking a single object whose appearance does not change. Third, when the operational envelope is severely constrained: an embedded device with no GPU, a deployment whose entire compute budget is a few hundred milliseconds on a low-power CPU, a regulator who needs every step of the pipeline to be inspectable.
Deep learning wins reliably under the opposite conditions. The scene is variable; the appearance of the target changes with lighting, viewpoint or occlusion; there are enough labelled examples to support training; latency budgets allow a meaningful inference run on a capable accelerator. Detection of a class of objects whose appearance the team cannot fully describe, segmentation of organic shapes, OCR on documents whose layout is genuinely heterogeneous — these are the canonical cases.
The interesting middle ground, and the one where most production decisions actually live, is when both approaches will work but only one will age well. Our rule of thumb is simple: if a competent vision engineer can write down the algorithm in a paragraph, and you can imagine debugging it three years from now without retraining, choose classical. If they cannot, choose deep learning, and accept the operational obligations that come with it — the labelling pipeline, the periodic retraining, the drift monitoring, and the explanation interface that someone will eventually have to build for an auditor.
A specific anti-pattern is worth naming: the team that reaches for a pre-trained network on a problem that classical methods would have solved in a week, simply because the latter is less prestigious. The cost of that decision is not visible at deployment; it is visible eighteen months later, when the network has drifted, the labels have aged, the engineer who trained it has left, and the operations team is being asked to explain why a barcode reader requires a CUDA driver.
The opposite anti-pattern is equally common: the team that insists on a classical pipeline for a problem that has clearly outgrown it, on the basis that the domain is well understood. The signs are unmistakable — a thicket of conditional thresholds that no one quite trusts, a stream of edge-case bug reports that each require their own special-case branch, an accuracy ceiling that has not moved for two quarters. When you see this, the rational move is to retire the pipeline, label a few thousand examples, and ship a network that the team can actually maintain.
The honest answer, ten years on, is that the choice has never really been about the method. It has always been about whether the system you ship today is the one you will still want to be running, and explaining, in 2030.