What Computer Vision Taught Me About Software Engineering
Lessons from applied computer vision that turned out to be lessons about software in general.
I didn't expect working on computer vision to change how I think about software in general. But a handful of lessons kept showing up — and none of them were really about vision.
You can't improve what you don't measure
In a vision system, "it feels better" means nothing. You need a number: precision, recall, false-positive rate. The moment you define that number honestly, half your assumptions fall apart, because the metric rarely agrees with the demo.
Regular software is no different. We just get away with vibes for longer. "The page feels fast," "the flow seems clear," "users probably understand it." A vision project forces the discipline early: decide what good means, measure it, and let the measurement argue back.
The data is the system
A model is downstream of its data. Feed it thin, inconsistent examples and no architecture will save you. The most effective change is almost never a cleverer model — it's better, more representative data.
Once you've felt that, you start seeing it everywhere. The inputs are the system: the config, the content, the rules a product accumulates. The code is often just the thing that processes them. Improve the inputs and the behavior improves, quietly, without a rewrite.
Edge cases aren't edge cases — they're the product
Detecting an object in a clean, centered photo is easy. The whole job is the awkward cases: bad lighting, partial views, look-alikes. That's not noise around the product. That is the product.
Software teams tend to treat edge cases as cleanup for later. But the difference between a demo and a real system is almost entirely how it behaves on the inputs nobody designed for. The interesting work lives at the edges.
Humans belong in the loop
The most reliable vision workflows I've seen weren't fully automated. They paired the model with a fast human review step — the model proposes, a person confirms or corrects, and that feedback flows back into the next iteration.
That pattern generalizes. Full automation is seductive, but a well-placed human-in-the-loop often beats it: cheaper to build, easier to trust, and it keeps improving because the corrections become signal.
What I took away
Computer vision didn't teach me a new framework. It taught me older lessons more sharply: measure honestly, respect the data, design for the edges, and keep a human in the loop where trust matters. The domain was new. The engineering wasn't.