To Find the Answer, You Must Know the Answer
I've been reflecting lately on something the great Professor Emeritus Michael Collins taught me in my very first engineering lecture at the University of Toronto. He explained his fundamental principle of engineering, which has stayed with me and feels more relevant than ever today:
"To find the answer, you must know the answer."
At the time, it felt paradoxical. How could you know the answer before you've found it? I thought about that line often over the years, but I didn't fully understand the power of it until recently.
What Collins was getting at wasn't circular logic. You can't search effectively if you don't already have a sense of what "right" looks like. You can't evaluate progress if you don't know where you're going. And you can't tell whether an answer is correct unless you already understand the shape of correctness.
That idea has quietly followed me throughout my career. And today, as the nature of knowledge work itself begins to shift, it feels ever more like the organizing principle of the moment.
Execution is Getting Cheap. Knowing Isn't.
As systems of AI agents become more capable and more accessible, the cost of execution continues to fall. Models get better. Tools get faster. Per-unit effort keeps trending toward zero.
In a world where execution is cheap, the value chain must rebalance itself.
The "doing" becomes free.
The "knowing what to do" becomes the bottleneck.
This is easy to say abstractly. It didn't really click for me until two weeks ago, when I watched our team at OutRival do what should have been impossible.
48 Hours
Our VP of Engineering walked in one morning with a crazy idea. The kind of crazy idea that had never been done before and would completely transform the product. It broke the mold of everything we'd built and would require a complete re-architecture of core systems. New architecture. New database. New services. Entirely new capabilities.
We wanted it shipped before the holidays.
What followed was a 48-hour sprint that fundamentally changed how I think about engineering work. We leaned into our AI agents, completely trusting implementation to them, while we spent our human time whiteboarding & brainstorming in parallel.
Not writing code, but defining the end state.
They were working to find the answer. We were working on the answer.
Collins was right.
By the end of the second day, it was done. None of this would have been possible a year ago.
Knowing the Answer Isn't a Checklist
What made that sprint possible wasn't that the agents were fast to generate code. It was that the humans involved were experienced enough to know what they were looking for.
"Knowing the answer" isn't a checklist. It doesn't operationalize cleanly. It varies by domain, by system, by problem. It's an intangible skill that comes from years of building things.
But while it can't be formalized, it leaves fingerprints. Looking at output and feeling that something is off. Knowing which abstractions are wrong. And anticipating failure modes you've seen before.
Delegation Exposes the Gap
AI agents are an accelerant. They amplify whatever direction you give them.
If you know what you're building, they can collapse timelines. If you don't, they scale confusion just as fast.
Effective delegation means taking your hands off the wheel. Learning to let AI do the building while you focus on directing, reviewing output, and rejecting what doesn't fit.
Those who lean into this will be able to do the work of entire teams.
The Engineer's Role is Moving Upstream
As someone who's written code for most of my career, this shift is jarring. There's something unsettling about being mostly hands-off. But it's also freeing.
Embracing this shift is accepting a kind of promotion. I'm now the CEO of anything I build, with a team of agents writing code and managing the product while I set direction.
My job isn't to do the work anymore.
It's to know what done looks like, and to recognize when we're not there yet.
That's the principle in practice.
To find the answer, you must know the answer.